Comments on The Challenge of Dashboards and Portals

Jonathan Baker-Bates — Wed, 07 Nov 2007 13:23:25 GMT

I’ve just noticed you’ve gone from having 1 reputation point on 2007/04/24 to 104 now! Congratulations! It’s taken me many years of hard fighting to get my 12…

I need to read your articles some more to get a better understanding of the finer points, I think. Right now, it seem to me a logical approach, but I’m not sure how close it is to what I’ve been doing for a while already.

Joe Lamantia — Mon, 05 Nov 2007 21:43:26 GMT

@Jonathan: Sounds like the dashboards you experienced were exceptionally well-organized :) Yes, relevance and proper contextualization are critical; so much so that they’re often some the first things that get attention during design. As information spaces grow over time – or grow very suddenly with mergers / acquisitions / reorganizations – the organization of the dashboard or portal frequently emerges as a substantial challenge. Anyone who’s done portal work can attest that these architectural and structural problems only increase with passing time.

What layer of the experience do you have in mind when you mention design? You’ve probably taken this to heart already, but I should mention that the building blocks are built to address quite a few layers of the dashboard environment at the same time. They do so by serving as a consistent conceptual framework – a framework that is very often rendered visually, even as it affects visible aspects of the portal experience such as screen layouts, navigation design design, content models, etc.. In other words, scratch the surface of any layer (visual, interaction design, information architecture) and you’ll find the building blocks showing through.

It’s difficult to think readily of dashboards that are not built on tiles. Perhaps something similar might be the business intelligence and reporting toolsets that allow direct manipulation of data sets and data feeds, in real time. But these are largely dedicated tools / applications, which do not provide additional functionality outside the BI / reporting category (so no social mechanisms for supporting discussion, analysis, and identification of consensus to drive decision making).

Jonathan Baker-Bates — Mon, 05 Nov 2007 17:31:05 GMT

Having used a few dashboards over the years, I’d say the biggest challenge is not in their organisation (although that’s always a problem) but relevance of the data and whether or not its contextualised in a way that the user can act on.

Be that as it may, I’m intrigued by your articles on this. I’m trying to think of a way of designing a dashboard that was not based on some form of tile-like design, but I can’t. Is there anyone not doing this? I’m a bit confused.

naveen sethia — Sun, 28 Oct 2007 14:31:35 GMT

Great Article Joe – I like the idea of tile library. Looking forward to read the remaining article in this series.
I am a student now, doing masters at TU Delft, before that I was designing dashboards for one of the big software company.

Joe Lamantia — Sun, 30 Sep 2007 19:06:10 GMT

@Kiran: I’m compiling a list of related reading, to share as part of the series. I haven’t read Stephen Few’s book, but I’m looking forward to it. What other sorts of material would you recommend looking at?

kiran mova — Wed, 26 Sep 2007 18:42:44 GMT

Great Article Joe. Very helpful for people like me starting with their first dashboard design projects. As Chris pointed out, Stephen Few has a good book on dashboard design and helps understand the cognitive science behind the layout, shapes and colors. However, it does not cover the design strategy that needs to be developed. Looking forward to read the remaining articles in the series and hope they are aligned with the theories from Edward Tufte and Stephen Few.

Joe Lamantia — Wed, 27 Jun 2007 15:16:17 GMT

Thanks Patrick – I’m glad you find them useful. The most important step toward sharing and discussing something is having a name for it, thus the joke that the first law of Information Architecture is “It’s all about labeling”...

As far as I know, these terms originate right here :) But I haven’t done a thorough search for other examples. You might try some of the growing crop of books on portal and dashboard design available from various publishers to see what they have to say. These books were not available when I first developed the building blocks (now a while ago). Let us know what you find?

Patrick Stapleton — Wed, 27 Jun 2007 04:26:35 GMT

What stands out for me as useful in this article is your screen overlay. “Section Connector”, “Page Connector”, “Control Bar”, “Convenience Functionality” etc – these are really useful terms that I’m going to use going forward. Did you invent these or are they from something that I should read ? :)

Joe Lamantia — Tue, 24 Apr 2007 15:17:00 GMT

Chris – thanks for commenting. I’m afraid the purpose of the article may not have been clearly communicated, based on what I understand your comments to refer to. This article is the first in a series that shares a system of IA buliding blocks that is meant to be support a high quality user experience for presenting *any* kind of information / content / functionality, in an easily understood structure that can grow over time.

That means that the context for this article is the consistent set of design challenges teams must face when working on any dashboard, or tile based content aggregator. This design framework is meant to be independent of other contexts, such as industry or the functional role of the users.

Keep in mind that large organizations often need several kinds of dashboards or consoles, addressing diverse needs for information about the organziation at mulitple levels, and from multiple perspectives. Perhaps the specific label ‘executive dashboards’ leads away from the underlying idea of the building blocks – that one design toolkit can help solve many problems faced in the creation of a large range of tile-based experiences. In large organizations, a suite of interlocking dashboards is not uncommon; at the true exeuctive level, these consoles may be genuienly global in scope, but at lower levels of the organizational hierarchy, they may concern only a single region, product, or business unit.

Also be aware that the examples of dashboard screens and UI components are intended to show how to use the building blocks to design this sort of flexible structure, not to show proper information design for any specific set of content. As you’ve noticed, the examples show comps (or in some cases, sanitized screenshots from some of the ~25 actual dashboards built using this system of blocks) that emphasize the structure deliberately.

All that said, your points are valid. Context is essential for the proper understanding of information, and you’ll see some specific mechanisms built in to the buliding blocks that are intended to help preserve the context of information sourced from many different places. The structure should fade into the background and allow the information to be most prominent – thus the disclaimer that the renderings and exmaples here are not meant to be taken literally as design guidelines for any sort of dashboard, or tile-based experience.

Thanks,
Joe Lamantia

Chris Gerrard — Wed, 26 Sep 2007 18:43:09 GMT

There is substantial merit in the idea of having a foundation technology useful for the construction of dashboards. I quite like the idea of having a coherent architecture from which dashboards can be rationally constructed.

However, the article misses the central point of dashboards, particularly executive dashboards: presenting enough information *in context* to provide a comprehensive analytic overview of the entire scope of the organization being examined.

To quote Edward Tufte, “Above all else, show the data.”

High quality analytic information design of a dashboard is the central factor leading to its success. In order to be effective dashboards must be information-dense and present the information clearly.

Practically speaking, this means that, as much as possible to “machinery” of the dashboard must give way to the information. The machinery must take second stage, to the point of fading completely away.

The article concentrates on the structural technical elements involved in dashboards, to the near-exclusion of good analytical information design. For example, Figure 2 labels 8 distinct structural elements but none of the data displays.

Illustrative of information design improvements that should be made in the sample dashboard…
The top two leftmost tiles show related measures for the same seven products in two line graphs covering the same time period. The As of date is the same for both and is shown four times. The product legend is duplicated, wasting precious space, as do the heavyweight title bars and non-data ornamentation.
It appears that the information in the graphs is possibly completely orthogonal in that the top graph show sales volume for each product, the bottom graph the proportion of total sales for each. This begs the question as to whether there is any additional information provided by the bottom graph. It’s hard to tell, but seems unlikely. (it would help if the graph were clearly labeled as % of total sales per product). If the second graph adds no additional information it should not be presented; if it does the presentation of the two graphs should be improved to convey their content and relationship more clearly.

An excellent resource for dashboard design is Stephen Few’s book “Information Dashboard Design The Effective Visual Communication of Data”, available from O’Reilly (http://www.oreilly.com/catalog/infodashboard/) and Amazon (http://www.amazon.com/Information-Dashboard-Design-Effect…)

daniele galiffa — Fri, 26 Jan 2007 14:53:47 GMT

Very interesting content.

Dasjboards design, when related to infovis methodlogies and techniques, could also offer new way to understand business trends and / or issues to be solved.

James Robertson — Fri, 26 Jan 2007 14:53:47 GMT

Great article! This is a space that seriously needs some vendor-independent thinking, so I’m very much looking forward to the rest of the articles in the series…

Joe Lamantia — Fri, 26 Jan 2007 14:53:46 GMT

I’ve created a suggested – and *highly* original – tag for bookmarking items related to the building blocks: ia_building_blocks.

I’ve tagged a few items on del.icio.us – my default bookmarking service – but monitor tag streams from some of the other bookmarking services.

http://del.icio.us/tag/ia_building_blocks

Joe Lamantia — Fri, 26 Jan 2007 14:53:46 GMT

Thanks! The building blocks are useful for most tile-based design approaches, so if another type of portal better meets your needs, don’t think the blocks require thinking specifically in terms of a dashboard.

slither slither — Fri, 26 Jan 2007 14:53:46 GMT

excellent article! i’m looking into using the dashboard approach for a project i’m working on now. i’ll be looking forward to your next series of articles covering this topic.