Comments on Connectors for Dashboards and Portals

Joe Lamantia — Tue, 19 Feb 2008 02:49:03 GMT

Nilesh,

As a good consultant, I recommend going with the development / architecture / build model that best suits your needs :) At this point, many of the technology elements of a complete dashboard solution architecture are available from several vendors (and perhaps in Open Source form as well, though I’m not familiar with any OSS dashboard packages).

The building blocks will allow you to define a vendor-neutral design – which should make comparison of any specific combination of build vs. buy components for the overall solution much easier.

I’d check with dashboard vendors directly to see if they implement the building blocks in whole or in part (I’m not aware of any at the moment), or any similar design / architecture framework that the blocks can align with.

-Joe

Nilesh jethwa — Fri, 07 Jan 2011 19:42:05 GMT

Are you suggesting use of custom Dashboard Development from scratch? Do you know if this framework is implemented in any vendor specific tool?

-Nilesh
Design and Develop Dashboards

Joe Lamantia — Thu, 06 Mar 2008 16:38:57 GMT

@Dmitry: Geogrpahy selection is indeed a kind of parameter. It’s a very, *very* common parameter for global / international organizations: I’ve seen it used in almost every medium or larger effort I’ve participated in. In the case of Geography, it was the close association with “place” in the minds of users that drove the decision to identify it as a specific type of Connector, rather than just mentioning it as one of many possible parameters.

In early uses of the blocks, we found many people expected to be able to ‘navigate’ to a ‘page’ for each geographic locale, and expected to do so by seeing those possible navigation choices displayed as conventional navigation / browse structures composed of hyperlinks. Using the Control Bar to choose a geographic context took a bit of getting used to, (this was before the broad acceptance of RIA, but still holds true in many cases) and so we bridged the mental gap by creating a specific kind of Connector.

Also, looking ahead, identifying a Connector based on this single parameter seemed a good way to illustrate the potential for adaptation and extension that is inherent in a framework like the blocks. Language is another great suggestion for a standard type of Connector. Currency, unit of measurement, and time span are all also quite common. I’d hope to see people extending / refining / enhancing the building blocks exactly this way.

Thanks for the great feedback!

Dmitry Nekrasovski — Thu, 01 Nov 2007 21:50:54 GMT

Nice article and series in general. Dashboard/portal design is definitely in need of a pattern language like the one you’re proposing.

The Geography Selector component, in my opinion, is more generically about parameterizing a Container with respect to some attribute, which doesn’t have to be geographical in nature. For example, I am currently working on e-commerce store management application where a similar component provides the ability to switch the language in which product data is displayed in the Container below.

Looking forward to Part 5!