Photos for interaction

by:   |  Posted on

When developing user interfaces, designers increasingly use custom graphical elements. As the web browser becomes basic technology for software interfaces, more and more elements derived from graphic and web design replace the traditional desktop approaches to the concrete design of human-computer interfaces.

In the near future, this development will become even more relevant. The barrier between web pages and desktop software is beginning to disappear, and modern rich client user interface technologies such as Silverlight/WPF, Air, or Java FX enables designers to take the control over the whole user experience of a software product. Style guides for operating systems like MacOS or Windows become less important because software products are available on multiple platforms, incorporating the same custom design independently from OS-specific style guides. Software companies and other parties involved begin to use the power of a distinct visual design to express both their brand identity and custom interactive design solutions to the users.

While this implies a new freedom for designers working in the field of interactive software products, it strengthens the importance of visual design for the design of user interfaces. Designers working on concrete graphic solutions for a specific interface are breaking away from established standards defined by a software vendor. It is now the responsibility of those user interface designers to choose graphical elements wisely to make a product’s interaction principles visible and usable.

Continue reading Photos for interaction

Cues, The Golden Retriever

by:   |  Posted on

In every waking moment, our brains are processing the stimuli in our environment and responding, consciously and unconsciously, to what is going on around us. This may mean something simple like stopping automatically at a crosswalk based on the color of the traffic signal. Or it may mean something more deliberate, like deciding to turn left after orienting yourself by reading a street sign.

Both consciously and unconsciously, we also make decisions while interacting in an onscreen environment. We move automatically during routine tasks and through familiar interfaces. But what do we do when the interaction onscreen requires a very deliberate and thoughtful interaction—how do we determine the correct response to the stimulus? We need cues to help us draw from our experience and carry out an acceptable response. Cues are like little cognitive helper elves who prompt us toward a suitable interaction, reminding us of what goes where, when, and how. Cues can be singular reminders, like a string tied around your finger, or they can be contextual reminders, like remembering that you also need carrots when you are shopping for potatoes and onions in a supermarket. Continue reading Cues, The Golden Retriever

Enhancing Dashboard Value and User Experience

by:   |  Posted on

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

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

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

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

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

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

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

A Portal Design Vision: Two-Way Experiences



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.


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.


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.


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.


Figure 3: Local vs. Source Experiences


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.


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.


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.


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.


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.


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

by:   |  Posted on

iTunes     Download     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
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

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.
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!”
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.
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.
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.
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.
Christopher: That’s good, that’s good, yeah, yeah.
Daniel: Yes.
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?
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]
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, 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]
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.
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.
Christopher: Like star people, blue star people, would have worried so much.
[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

by:   |  Posted on

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

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

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

Part 4 describes the Connector Components in detail.

Overview of the Connector Blocks

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

The defined Connectors are:

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

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

Container Definitions

Each Connector definition includes:

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

Control Bar definition

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

Control Bar description

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

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

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

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

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

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

Example rendering:

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:

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

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

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.


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:

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.


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.