Enhancing Dashboard Value and User Experience

Written by: Joe Lamantia

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

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

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

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

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

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

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

A Portal Design Vision: Two-Way Experiences

Recommendations

Metadata

Presentation Standards and Recommendations

Manage Functionality By Creating Groups

Enterprise 2.0 and the Social Portal

A Portal Design Vision: Two-Way Experiences

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

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

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

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

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

Recommendations

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

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

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

Convenience Functionality

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

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

The collection is broken into five groups:

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

The illustration below shows Convenience functionality associated with a Tile.

convenience_functionality_c.jpg

Figure 1: Tile Convenience Functionality (By Group)

Group 1: Understanding Content Sources and Context

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

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

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

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

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

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

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

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

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

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

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

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

Group 2: Making Dashboard Content Portable

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

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

Group 3: Controlling the User Experience

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

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

Group 4: Staying Aware of Changes / Subscriptions

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

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

Group 5: Social and Collaborative Tools

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

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

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

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

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

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

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

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

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

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

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

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

Stacking Blocks

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

combinations_convenience.jpg

Figure 2: Combinations of Functionality

Convenience…or Connector Component?

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

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

Utility Functionality

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

Common Utility functions include:

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

My Experience or Yours?

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

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

utility_ux.jpg

Figure 3: Local vs. Source Experiences

Metadata

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

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

Administrative Attributes:

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

 Structural Attributes:

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

 Descriptive Attributes:

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

Metadata Standards

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

Presentation Standards and Recommendations

Visual Design and Style Guidelines, Page Layouts, Grid Systems

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

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

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

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

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

standards_view_border.jpg

Figure 4: Presentation Standards for Containers and Connectors

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

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

standards_block_content_border.jpg

Figure 5: Presentation Standards for Chart Content in Container Blocks

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

Container States

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

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

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

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

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

states_comprehensive.jpg

Figure 6: Tile: Comprehensive Display

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

states_summary.jpg

Figure 7: Tile: Summary Display

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

states_snapshot.jpg

Figure 8: Tile: Snapshot Display

Convenience and Utility Functionality

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

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

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

Manage Functionality By Creating Groups

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

Other recommendations include:

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

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

Enterprise 2.0 and the Social Portal

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

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

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

Using Design Visuals To Communicate Ideas

Written by: Jeff Parks


iTunes     Download    Del.icio.us     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gifIn late January I had the pleasure of attending the VizThink conference in San Francisco. As an Information Architect I wanted to learn how to use different ideas around design to assist me with “big IA” and “little IA” projects. The folks kind enough to join me in this conversation include:

Christopher Fuller Griot’s Eye
Daniel Rose Bell Canada
Ken and Rebecca Hope Motive8 Infographics
Noah Iliinsky Complex Diagrams

We discuss:

*Thinking outside the box* Daniel Rose talks about why the process of “thinking outside the box” isn’t possible unless you surround yourself with people of different experiences. The following framework is what Daniel sketched during our conversation that describes his idea.

*Graphics empowering people* Ken Hope from Motive8 Infographics points out that a lot of the visualization tools empowers people to communicate ideas more clearly, without having to use words.

*Global Perspective* Noah Iliinsky and Rebecca Hope talk about the diversity of professionals, both within and outside of the design disciplines in attendance, and how the sharing of different perspectives added even more to the conference itself; backing up Daniel’s perspective of thinking outside the box. (In fact, 21% of the participants were from outside North America.)

*Common Craft* One of the many presenters at VizThink were the founders of Common Craft, Sachi LeFever and Lee LeFever. Rebecca points out that the end result is brilliant, but not knowing the work that goes into creating these simple, yet elegant videos, is common amongst clients.

*To Write or not to Write, that is not the question* Daniel points out the genius behind Common Craft is the writing or scripting of the videos that make Common Craft remarkable. Writing and illustration go hand in hand.

*KISS* Taking the time to reduce the noise will help your users understand the core message – whether it’s in design or writing to help guide the vision.

*Want to see more of VizThink ’08?* There were several photographs taken by professional and amature photographers while at the conference. For most of the photos, check out Flickr and search on the key word “vizthink08”.

*Examples of Design*
The following are images were created by Christopher Fuller; Ken and Rebecca Hope; and Noah Iliinsky. For a full size version of this art work, simply click on the image.

*Christopher Fuller*
This is a recent live illustration record I did of a dialogue on branding (The original is 12.5′ X 6.5′) that was given to a European banking client by Scott Bedbury – a former Nike and Starbucks marketing executive.

Just a little note of clarification on why I drew Lech Walesa in the bottom left corner. Mr Bedbury told a story about Lech Walesa coming to the United States to give a talk at a conference. One of the employees at the hotel saw Lech’s name in the register as a featured speaker and decided to google him. They discovered that his birthday fell on the same night as his speech, and so they arranged for the hotel wait staff to learn how to wish him happy birthday in Polish. According to Scott, it brought Lech to tears. It was a great story and one I knew I had to capture.

I do have the ability to do a reasonable caricature of Lech Walesa on the fly being a child of the 80s, history buff, and someone who gobbled up pop culture (um, there’s a prominent nose, moustache, etc.). But I don’t know how to write “happy birthday” in Polish. So while scribing the conservation I whispered to a colleague to google how to write the phrase and slip it to me on a post-it (I took my cue from Scott Bedbury’s story and copied the initiative of the hotel worker). By the time the conversation was over I had written “Wsystkiego najlepszego Lech Walesa” on the graphic. Of course, this went over well (though I think it’s not 100% right) since the meeting was in Europe and there were a few Polish participants in the audience.

*Ken and Rebecca Hope*
This infographic is a classic example of a “before” and “after” and shows why we love what we do! The client, Ifor Ffowcs-Williams, CEO, Cluster Navigators Ltd, is an international cluster development consultant.

In his workshops Ifor’s verbal communication is eager and interesting. However, his key presentation tool detailing the underlying process just didn’t do him justice as a typical Powerpoint slide. Although he is a visual thinker and speaks using lots of imagery and analogies, his presentation slides were all plain written text (even though occasionally highlighted for effect!) and didn’t capture the excitement or essence of what the process involved and offered. Also, when used with audiences with limited English, the text-based slides were not always understood.

Essentially we brought the Cluster Navigators process to life. We visualised the process as a fun and dynamic journey, using simple imagery for each key stage to help audiences quickly understand the concepts and engage in the process.

The impact of the the infographic is probably best described by Ifor himself in this feedback he provided, “Why didn’t you show us this before?’ was the question from one of their Scandinavian clients on seeing our new infographic. “We’ve now used it in workshops and conferences on five continents. It’s brought out the smiles, made the learning more interactive and led to repeat business.”

*Noha Iliinsky*
This diagram has been arranged to show not only the hierarchy, but also the intended use pattern of a typical, linear, non-fiction book.

* Continuity in the book is indicated by contact of the circles.
* The gray line, progressing in small and large clockwise arcs from section to section and chapter to chapter, demonstrates the linear progression of the content.
* The dashed black arrows show some possible non-linear paths that may be traveled by the reader to view content that is not part of the main linear flow of the book.

The goal of displaying the use of the book, and not merely the hierarchy, has led to an atypical diagram that conveys more knowledge than the typical counterpart.

I created this diagram in the fall of 2003. It appears in my thesis, and was selected to be supporting material for the book The Practical Guide to Information Design, by Ronnie Lipton.

Transcript of Using Design Visuals To Communicate Ideas A Podcast from Vizthink 2008
[music]
Jeff Parks: This podcast is brought to you by TechSmith. Right now, millions of peoples are snagging. Are you? And by, the IA Summit. This year, your peers and industry experts will speak about how topics such as social networking, gaming, patterns, tagging, taxonomies, and a wide range of IA tools and techniques can help, as users experience information. For other events happening all over the world, be sure to check out evensts.boxesandarrows.com.

In late January, I had the opportunity to attend the VizThink Conference in San Francisco, California. VizThink brought together some of the most creative minds in design from around the world. On the last day of the conference I gathered together Daniel Rose from Bell Canada; Ken and Rebecca Holt from the New Zealand based infographics company, Motivate; interaction designer Noah Alinsky, and illustrator and designer Christopher Fuller from Griot’s Eye.

We cover a range of topics, including “How to truly think outside the box, ” “The power of illustration and design in communicating ideas, ” and personal highlights from the conference. Many thanks to everyone for participating in this discussion, and I hope everyone enjoys the podcast. Cheers.

Jeff Parks: I didn’t really have a theme for today. I thought maybe we could just talk about lessons learned, why people are here, and what they’ve learned, what they’ve enjoyed about the VizThink Conference, in general. Maybe we can go around there and everyone can introduce themselves to start, and maybe, the company you’re working for, and what you do. Can we start over here?

Christopher Fuller: I’m Christopher Fuller. I’m from Los Angeles. I work for Griot’s Eye. It’s a huge vast company of one.
[laughter]
I network with friends a lot of times on bigger projects, but I do graphic facilitation, live illustration. My background is cartooning and caricature, which I usually do in Orlando. And I came into this because of MG Taylor Corporation, which was a boutique consulting firm that put an ad that they needed some artists. And I was like: “Why would consultants need artists?” And that began my journey.
Jeff: Cool, excellent. And you’ve enjoyed the conference?
Christopher: I did. I loved it. I knew that there was a community out there, but I was in a bathtub, sliding around. [laughter] And I came here and I was like, “Wow, there’s an ocean!”
[laughter]
So, it was great.
Jeff: Excellent. Rebecca.
Rebecca Holt: I’m Rebecca Holt, and I’m from Wellington, New Zealand, all the way across the Pacific. And my husband and I work in a company called
Motivate Infographics, which has been recently launched. After five years of playing around with infographics and the need for them, and clients that we could help communicate with, or for. And we launched Motivate at the end of last year, and most of the work we do is with the New Zealand government, where they have excessive documents, and reports, and processes which aren’t understood in your words. We go in and add the concept to our process and make them visual. People can quickly and clearly grasp the main points of anything.
The conference has been great. Same reason. New Zealand’s a very small country, a long way away. But it’s nice to be able to come and connect with other people who are also converted over.
Ken Holt: Well, I’m Ken Holt, the other side of Motivate Infographics. I too, by coincidence, come from New Zealand.
[laughter]
Noah Alinsky: I’m Noah Alinsky. I’m between projects right now. I’ve most recently been working as an interaction designer, which is what I went to graduate school for. But, accidentally, in the course of my studies at graduate school, I wrote a 90 page thesis about, how to draw good diagrams. And the basis of that is… the short version is that intentional choices are more powerful than arbitrary choices. So, the process steps you through the choices that you make when designing a diagram, or a visual representation, and how to make those good choices, based in cognitive psychology, and how people perceive things, like shape, and placement, and color.
So, at the end of the day, what you get is a product that is an information product that’s useful to your audience. And mostly, I’ve done work applying that to qualitative things: to pictures of relationships. But the same concepts are completely valid also for any kind of quantitative, numeric representation. So, I’ve spent a lot of time thinking about that.
Daniel Rose: My name is Daniel Rose. I’m from Toronto, Canada. And I work for a company called Bell Canada, big phone company. You may have heard of it.
[laughter]
You’ve heard of it in New Zealand. Alright, that’s good. I work with large groups, around specific business objectives, to coalesce the energy and passion, and wisdom of those groups and put it together into something that is useful for organizations. What I would call a ‘tangible work product’, that is created quickly, in real time, with the knowledge and expertise of everyone in the room.
Jeff: I know the one thing I was talking to you guys earlier… one thing that I really got out of this conference as an information architect, is really wanting to understand, how to better design ideas; better design products and services. Like Rebecca, I work with vast, huge volumes of data, trying to structure and label things so people can easily find them and then move their way through a process, whether it’s on a website, or otherwise.
There’s a lot of tie‑in: interaction design is very much like that. And I just found it really interesting with the different workshops, the way in which people would do things. I attended Daniel’s session this afternoon, and Christopher was trying a lot of things brilliantly, and we got to interact with everything from Play Dough to cut and paste of Styrofoam balls.
You don’t really think about these things that, I guess I would have used in grade one and grade two as a way of working with large companies, to try and illustrate ideas. He gave a great presentation today, Daniel, and again, it’s just thinking outside the box a little bit more, in terms of presenting ideas.
Daniel: I have some thoughts on that box, too.
[laughter]
Jeff: OK, well let’s hear them.
Daniel: Sure, alright, we’ll make it quick. So, I would suggest that thinking outside the box is not actually possible. The box is what it is. So, when people are asking that; asking to get that, I’ll define the box, first. In my humble opinion, the box is defined by: the boundaries of the box are the collection of our knowledge and our experience. That’s the box. So, when you’re looking for creative or breakthrough ideas, what tends to happen is that people tend to get with like‑minded people. And, they tend to be with small groups of people, as well. They don’t want 50 people looking for breakthrough ideas, because that’s unmanageable.
So, they get in a room with five people who are just like them. So, the collective box is the sum total of that knowledge and that experience, which is really, ultimately, quite small, because they’re all the same. They’re all say, “Telecom people.” They all went to the same university, and they’ve all worked at the same telecom for 20 years. So, the potential for breakthrough ideas is limited.
So what you need to do then is you need to…and I’ll draw it out. This probably won’t help for you podcast listeners.
Jeff: We’ll take a picture of it and put it up on the show notes.
Daniel: All right, perfect.
Jeff: No problem.
Daniel: So if you get a bunch of people together who are all kind of similarly minded, there’s your box. If you get a bunch of people together who are all very different ‑ artist, sculptors, musicians, different industries, different places on the earth, different ages ‑ that becomes the size of your box. And the potential for creativity and innovation is when these people start to talk, and they start to share mental models, and they start to rebuild mental models based on the unpacking of their assumptions and rebuilding it. So that’s where your potential for innovation and creativity can occur. The thing is it takes time.
Jeff: Right.
Daniel: So if you’re talking with a nuclear physicist about what they mean by the word “merger”, they’re going to be talking about the coming together of electrons and atoms or whatever, and it’s going to mean something completely different to a business person. And then you start to unpack, OK, well what does it really mean? What does it really mean? What does it really mean? And then you can start to co‑create together. So then you can have the insight and brilliance of a physicist to help you work through your corporate direction with ideas and perspectives that you never would have come up with on your own.
Ken: Might start a completely different change of direction which the businessman’s never even contemplated before.
Daniel: Exactly. But this takes time. The act of these different parties coming together to exchange and unpack their models is a time consuming process. So you have to think about, is that a good investment. Is the challenge that I’m currently dealing with significant enough that I need to invite physicists and sculptors in order to really get into it? If you’re just looking to redo your something or other, how do you bring people into the company through a website…maybe you don’t need that. You just need to think about what your objectives are.
Rebecca: And out of interest are you seeing more and more companies willing to take that step to want to bring in outsiders and such who might not know anything about the business but then are actually, OK, let’s go for it. Let’s see what can be possible. Let’s see what ideas we could come up with.
Daniel: It’s getting there. I think that’s almost the most extreme manifestation of that. I’ve worked with some clients who instead of doing that, instead of inviting the sculptor and the physicist in, they take a whole day to rethink their business processes after reading for a couple hours about complex adaptive systems. So we’ll have people reading about how coral reefs manage resources and how rainforests do the same. And that’s one way to substitute for actually getting a marine biologist in or something like that.
Ken: It’s kind of like what Tom was saying that it’s almost a poor substitute because you look up on the Web for this sort of information, and you’re still using your assumptions and your box view. Whereas if you’re actually sitting in a whole room of people, that’s like you said, they could have done this all over the Web. But the scope of what we’ve done and what we’ve learned and the enthusiasm could not be captured through a single conduit like that.
Daniel: Yeah, it’s a continuum and you just have to figure out where the payoff is.
Ken: Time is the cost of getting these ideas but wow, look at the directions you could go in.
Jeff: Even from a human factors perspective, your brain is made up of two hemispheres and we tend to not really exercise the one half very much, in our professional lives in particular. And I think that’s the one thing that focusing on design more for solutions can really help with because the more you engage in creative processes, the stronger your logic becomes as well, in very much layman’s terms but that’s the general idea. And so if we had companies that were more involved to be, looking at Chris’ illustrations for example ‑ we’ve got to get pictures to put up on the podcast. You’re an absolutely brilliant artist. When we were here the first night…
Christopher: Go on.
[laughter]
Christopher: That’s good, that’s good, yeah, yeah.
Daniel: Yes.
Christopher: Griotseye.com.
[laughter]
Jeff: I resemble that remark. But you are. You’re absolutely brilliant. And looking at your illustrations the other night you could just tell. I didn’t need to say anything. You could just look at the illustration and you could just envision exactly what you were thinking. The whole conference blew me away in terms of the unbelievable talent that’s out there. And we’re not alone, right?
Christopher: I think that’s the real power of when you add the visual modeling element. When people see ideas that they’re saying coming to life in front of them it’s just such an amazing experience.
Ken: Empowering.
Christopher: It’s empowering, people hear their ideas being captured. And like you said they’re empowered, but also other people can see a pattern emerging, and it’s pretty amazing.
Noah: And that actually leads into something that I was very impressed by is that we’re under this umbrella of visual thinkers, but there’s cartoonists, and illustrators and mapmakers here, the mind mapping people who are very much about the contents and the relationships and not so much about the visual presentation. And I’m more at that end of the spectrum. People who can do all of it…
Christopher: Photographers.
Noah: Photographers. These groups working together and learning from each other. The illustrator is learning to structure and the logical people learning how to draw. I can do a stick figure now, right?
[laughter]
Noah: But everybody being excited about expanding our collective box really to creep in those directions that we didn’t have and having a community to do that in where we to a degree have this common goal of all of us expanding our capability of representing these ideas. Just like you said, being able to turn what’s stuck in our heads into something that we can share in a representative way.
Rebecca: And what’s cool about that also is how many university‑type teaching professionals are here too.
Ken: Oh, yeah, academics.
Rebecca: Covering a couple of educational people who are here to try and learn how to do this. It’s not just professionals in this field. It’s actually companies who want to do better and bring it into the organizations or lecture which I think is brilliant.
Ken: Or people who want to actively pass this on to the younger generation. That’s the kind of energy which I think everyone’s got to take. This is really just a new way of thinking.
Jeff: Because I’m part of a few mailing lists, the Interaction Design Association, the Information Architecture Institute, Taxonomy Community Practice. One thing I keep reading over and over again, which I think is a colossal waste of time, is trying to define the professions, trying to…you know what I mean?
Noah: It’s a thread on the IA list for 10 years.
Jeff:: I’m sick of it. It’s so irrelevant because let’s face it, if I were to draw a picture of what I wanted you to build, and all of the different professions that are sitting around this table, you’d all be able to build it. You’d have a different way of going about building it, but the product or the service or the site or whatever it was, you could build it. So what I really liked about this conference is, here’s an opportunity to learn from people in different areas, like you were all just illustrating, and not focusing on trying to define my own profession. But rather, opening up the doors and learning from others, and then incorporating that into my profession and learning accordingly. And stop trying to get into the semantical details of defining what information architecture is, or what interaction design is. I mean, to me, that just seems like such a waste of, I don’t know, brain power. You know?
Ken: Define through the big picture. Don’t define through the micro‑vision.
Jeff: Right. And Daniel’s big picture as, right? Not the little microcosm of like‑minded people, but all the larger box of professionals.
Ken: The ocean.
Rebecca:[indecipherable 15:27]
[laughter]
Jeff: Yeah, exactly. What were some of people’s favorite sessions that they attended? And maybe a short description of what they were?
Ken: One which I was super impressed with, wasn’t so much the session itself. Because it was about the growth, mind‑mapping. And, you know, he’s just a fundamental, flawless presenter, and he’s so onto it. But then, he, in the very last five minutes of his session, was all about the second life interactive reading environment. And so, he uses this basically to display these panoramic, huge pictures that they create, that they [indecipherable 16:12] .
Here’s a way of, what we normally do, is we draw a two dimensional information graphic. We boil the information we get down to the core message, and display it in a information graphic, that tries to encompass the whole.
Now that’s basically the core message, or the surface structure. Here’s a way of bringing this 2D image into a 3D environment, still keeping it 2D. But saying: “Look, here’s part of it. I want to know more, let’s open it up.” And suddenly, you get this 3D shelving effect, where you can actually open up part of the graphic and learn more about it. It links to websites, delve more into the structure of that particular part. And then: “OK, I’m getting a basic understanding of how that works. Let’s [indecipherable 17:01] together. Move that down, and open up this other part.”
So instead of giving just the overview, they’re giving the big picture. They’re getting the small picture, and putting it more into their framework that we’ve developed. And, I see that this could be a way of, basically adding much more detail to our end and to graphics.
And adding a fundamental step which allows people with the time and the energy, and the core need, to find out more about it. To allow some [indecipherable 17:31] to do so.
Rebecca: Other than Daniel’s session today, which was just a highlight…
[laughter and applause]
Rebecca: And the simplicity, or the cleverness of what they do, people keep saying, “Oh, well it looks so basic. And it looks… Anyone could do it.” And, as they pointed out, it’s not the look that’s simple. Or, maybe the look’s simple, but it’s the strategy. It’s what actually goes into choosing which simple images to put together. It’s what makes their…
Noah: The script?
Rebecca: It’s the script, yeah. It’s the script that really drives it together. And I think that’s what, a lot of what we all do, what people see as the end result. What actually has gone into the decisions that create that end result, often don’t really get appreciated. And it’s the strategy behind what you’re showing. And some of the examples you showed us today, Dan, made it all… It’s the decisions. It’s not just nice looking at diagrams. It’s been, you know, dozens, and dozens, and dozens of people work to create this masterpiece. In our case it’s just the two of us, but it’s nice even when it’s something really simple. Like at the Common Craft one today, they recognized just how much work goes into them. Yeah, just really cool people. So, that was a buzz, as was your session.
Daniel: And I was in that session as well, in Lee and Sachi’s session, Commoncraft.com. So, someone asked the question around, “It’s so simple that anyone can do it?” And I think the thing that’s going to them in business for a long time, is actually not the visuals, but the writing. I think people generally are either A, don’t like to write, or B, aren’t good at it. Or, C, think they’re good at it, but they’re not.
Noah: Well, they don’t take the time to do it. They just dive into the end product without doing the design phase. Of, what is the content we need to convey?
Ken: I’ve got a Mac, can’t do it. So [indecipherable 19:34]
[laughter]
Noah: Yes.
Daniel: But with respect to the actual, the visual component of it, I think that’s actually, it’s the writing. It’s not the visual that’s going to keep them in business, it’s the ability to write it.
Rebecca: And I think that… sorry, that reinforced, as several other workshops did, the need to keep things simple. That it doesn’t need to be complex. The visuals can be so simple, as long as the message is clear.
Ken: Cool message…
Rebecca: If the script is so clear, then the visuals don’t need to be more than colored little stick people.
Noah: And that was a very strong thread through two of the sessions I really enjoyed. I went to see Karl Goode, who is a professional information, informational diagrams, I guess. He worked for a music magazine for many years. And John Grimmway, who also has done a lot of map work. Maps of cities, and museums, and whatever. And both of them really were clearly very skilled at reducing the noise, and really focusing on: “What are the key things you’re trying to convey with this graphic?”
So, removing a lot of detail, removing a lot of extraneous color, removing a lot of text. Refining and refining and refining until… The core message remains. And it’s very clear and there’s not a lot of distractions. And, as the reader or the user, you can very easily access the information that it’s designed to convey, rather than having to dig through the text or dig through extra illustrations of things that aren’t actually relevant.
And so, this goes back to the writing. Having a really clear idea of, what is the message? What are we trying to achieve here? And using that to really guide the vision, which is unfortunately, infrequent, I think.
Rebecca: And that ties into what you and I have been talking about, Jeff, about the need to fully understand what the message is, and what it isn’t. The client’s actually trying to get across, or what the ultimate outcome is that they’re after. Because, unless you can figure that out front and you shouldn’t just start playing and throwing things.
Jeff: Yeah. Everyone’s really excited to dive in? Right? They want to get the project done, they want to see the end state. I mean, working with Canadian government clients, and I’m sure this is true in a lot of governments, they want to see the pretty picture. And from a graphical perspective, that’s great. But, when you’re dealing with vast, unbelievable amounts of data where no one can find anything, which is the whole purpose of the website in the first place. Arguing for three or four hours over what shade of blue the banner should be, right? Is kind of a moot point. Right? So, if we… Which is why wire‑frames are popular and why they’re effective, right? Because it focuses on the structure of where things are. And that’s a very basic, there’s another very basic visual tool kit that I know I use often, to get people to move away from looking at the specific colors of things.
Because that helps to put the final touches on it. But, OK, let’s focus on where you want things to go. Because very quickly after doing five or six wire‑frames, for example, they can see, “Oh, we’ve got about 16 different ways we structure content, and we’ve only got about five different ways we’ve drawn out so far, and we don’t have time to do 16 different structures of the information. And we don’t have time to create 16 different looking versions of each section of the site.”
So, very quickly it gets pulled back to the importance of the structure and the content, which in turn can drive the final look and feel. The designer I have back home in Ottawa, Bahn Forester, has been doing 15 years. He tells me all the time, design project that are maybe $500 quick projects, quickly turn in to $5000 projects for him. Not because he’s, you know… He tells the client up front, if you have the vision in place we can do this quickly, it can be done once.
But if you don’t have any of the content written and you have no vision for it, he just has to keep re‑changing everything. All the pixels have to change, the colors have to change. Again, he’s happy to take their money, as we all are, but if we focused more on that at the beginning then it wouldn’t be such a big issue, right?
Ken: To create a vision, you’ve to to have an end vision created.
Jeff: Right.
Ken: It’s not something that you work through.
Rebecca: It might evolve, but it’s a starting point.
Ken: It might evolve, but…
Christopher: Guys, my alarm went off, I’ve got to go catch my flight.
[crosstalk]
Christopher: I want to just leave quickly by saying I wasn’t actually in Scott McCloud’s session, but I was in the general session that he did at the end. That was very illuminating for me. It was brilliant, because, he outlined the dilemma that I find myself in sometimes as someone who’s come to graphic facilitation but from an illustration background. I’ve been blessed and cursed with the ability to draw very quickly, and kind of realistically sometimes. But, you know what? I’ve run into problems trying to find where I am inside his triangle of the real side, the iconic abstract side, and then the abstract beauty.
I remember working with a client and the line illustration went great. We were working towards a poster and I was doing cartoon people but they were kind of representative. Then the emails, edits starting going back and it was like, “You need to, the percentage of women needs. If you’re going to go that, we need some blacks.” Which is embarrassing because I’m African‑American. It got.
[crosstalk]
Christopher: Like star people, blue star people, would have worried so much.
[laughter]
[cross talk, several people say goodbye]
Christopher: … nice meeting you.
Jeff: Do people have other things they want to share, or chat about?
Daniel: I felt that the conference was more than just listening, like most conference are. I felt there was a spirit of co‑creation, that people wanted to create something new that hasn’t been done before. So, in the very literal sense, I think people really go into the exercise this morning in the general session around creating a plan for a not‑for‑profit organization called Art Train. Going back to my session content, that is a tangible work product. There were 350 people in the room who, in the course of 90 minutes, created work. Things were done.
Rebecca: The feeling that it will actually go on a mean something.
Daniel: Yeah.
Rebecca: The organization will absolutely use those ideas, or a lot of them.
Daniel: I felt that kind of, over the course of the couple days, let’s do something here.
Jeff: For those that weren’t here, the night before the conference started, what I really thought was interesting, they had massive large white boards they wheeled into the middle of the room, throughout the room. They left markers on them, so people could sketch and draw anything they wanted. And had different signs up about employers who are looking for people and people who are looking for work and they could put their names down. The organizer, Tom?
Daniel: Tom Crawford.
Jeff: Tom Crawford, the organizer of VizThink for this particular event, announced tonight that one person actually found a job. They were looking for someone and they hooked up. They had the interview and they landed the job, which I thought was pretty…
Daniel: That speaks your idea of something unique. You don’t hear about these things at every single conference, in terms of it being a priority, in terms of looking for those kinds of things.
Ken: In fact, I’d go so far to say, if you put white boards and markers up at most other conference, they would either be left untouched or what went on them would be just… complete vandalism, basically. You’d get the smart asses who’d do the “Kilroy was here” type stuff without really engaging that side of their brain. They would do a dump, rather an organized dump.
Noah: It was interesting for me the diversity of experience levels and skill sets here. A number of other conference I’ve been to, like the Information Architecture Summit, for example. Was more or less professions who were more or less doing the same thing. Some academics. This was very diverse here. There was educational administrators, there was graphic designers, and there was sort of information theorists, and illustrators, and cartoonists. In some ways I think it was a little bit challenging, because I think targeting the sessions and who they were for. I went to at least one session where I knew most of what went on, because I had much more experience with interaction design. It was a little bit lower level of that.
But, then, in the collaborative sessions where you had these different people working on a project, and people from all these different backgrounds and different parts of the country. Again, a nice big box. It was kind of interesting having all those different skill sets that, at least for me, mostly I don’t get that level of diversity of exposure in my workplace to these different skill sets.
They’ll be the customers I’m working with, and I’ll get some ideas from them, or some analysts or something, but that’s very different from having the diversity of people who were here.
Rebecca: A lot of that probably points to note for the people that weren’t here that they might find interesting is that 20% of the 380 people who were here, I think 380?
Ken: About that…
Rebecca: 20% were international and come from more than 3000 miles away. There were people from the UK, Denmark, Australia, New Zealand…
Jeff: South Africa.
Rebecca: South Africa. So there’s a pretty diverse bunch that all came together. And also that every meeting table, workshop table, and also the main session tables were covered in paper.
Noah: Yeah.
Rebecca: With a bowl full of crayons and pencils and stickers and sticky labels. I’ve never been to a conference like that in my life where you’re invited to doodle and draw.
Noah: Draw like a five year old, but here you’re encouraged to draw on the tables. And on the walls and the white boards. It’s almost like, complete reversal of what is expected of a professional, stiff‑backed person to come and doodle on a piece of paper or [indecipherable 29:20] . Just encouraged to lead the test. I feel like I’ve been at a fun‑park for an entire weekend. It’s just been like wow, wow, wow, wow, wow.
Rebecca: I think that the Vizthink website’s going to put a lot of the images from the conference up on their website. I’m sure people who are listening can go to that and see some of the cool photos that captured the essence of what it was all about.
Jeff: Guys, thanks very much. I know it’s been a great couple of days, but I’m sure everybody’s got plans for dinner, drinks, and maybe even heading home as Chris had to fly out. So, thanks very much for joining me on the the Boxes and Arrows podcast. Best of luck and I hope to see you at future conferences all over the world.
[crosstalk of everyone saying thanks]

Connectors for Dashboards and Portals

Written by: Joe Lamantia

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

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

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

Part 4 describes the Connector Components in detail.

Overview of the Connector Blocks

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

The defined Connectors are:

  • Control Bar
  • Section Connector
  • Page Connector
  • Dashboard Connector
  • Crosswalk Connector
  • Contextual Crosswalk Connector
  • Utility Navigation
  • Geography Selector

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

Container Definitions

Each Connector definition includes:

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

Control Bar definition

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

Control Bar description

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

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

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

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

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

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

Example rendering:

control_bar.jpg
Figure 19: Example Control Bar

Rendering description

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

Page Connector definition

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

Page Connector description

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

Example rendering:

page_connector.jpg
Figure 20: Example Page Connector

Rendering description

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

Section Connector definition

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

Section Connector description

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

Example rendering:

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

Rendering description

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

Dashboard Connector definition

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

Dashboard Connector description

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

Example Rendering:

dashboard_connector.jpg
Figure 22: Example Dashboard Connector

Rendering description

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

Crosswalk Connector definition

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

Crosswalk Connector description

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

Common examples of Crosswalk Connectors include:

  • product names linked to a summary Page or View of the identified product
  • topic terms linked to a news aggregator or RSS aggregator block that shows recent items related to that topic
  • competitor names linked to a profile snapshot or market intelligence block
  • market or product family names linked to sales performance blocks
  • colleague names linked to profile information blocks showing their role, responsibilities, and direct reports

Example rendering:

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

Rendering description

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

Contextual Crosswalk definition

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

Contextual Crosswalk description

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

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

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

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

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

Example rendering:

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

Rendering description

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

Utility Navigation definition

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

Utility Navigation description

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

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

Example rendering:

utility_navigation.jpg
Figure 25: Example Utility Navigation

Rendering description

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

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

us_products_example_callouts.jpg

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

Geography Selector definition

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

Geography Selector description

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

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

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

Example rendering:

geography_selector.jpg
Figure 26: Example Geography Selector

Rendering description

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

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

Conclusion

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

With proper assembly, using the stacking hierarchy and the small set of required elements, the information architect can create a consistent and scalable structure that supports a high quality user experience, lowers development costs and establishes a basis for sharing of resources across the enterprise.

Part Five of this series will describe a common set of utility and convenience functionality often used to extend the reach and relevance of dashboard content to other contexts of use, making practical suggestions for following the principles of Openness, Independence and Portability underlying the Building Block system.

Building Block Definitions (Containers)

Written by: Joe Lamantia

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.

tile_structure_2.jpg
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

tilegroup_structure_2.jpg
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.

views_structure_2.jpg
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.

page_structure_2.jpg
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.

section_products.jpg
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)
dashboard_small.jpg
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.

dashboard_suite.jpg
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

Written by: Patrick C. Walsh

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.

graphic1.png

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!’

graphic2.png

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.

Conclusions

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.