Comments on: Connectors for Dashboards and Portals http://boxesandarrows.com/connectors-for-dashboards-and-portals/ Boxes and Arrows is devoted to the practice, innovation, and discussion of design; including graphic design, interaction design, information architecture and the design of business. Mon, 20 May 2013 13:09:05 +0000 hourly 1 By: dmitryubc http://boxesandarrows.com/connectors-for-dashboards-and-portals/#comment-6823 dmitryubc Wed, 30 Nov -0001 00:00:00 +0000 http://boxesandarrows.com/connectors-for-dashboards-and-portals/#comment-6823 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!

]]> By: joelamantia http://boxesandarrows.com/connectors-for-dashboards-and-portals/#comment-6824 joelamantia Wed, 30 Nov -0001 00:00:00 +0000 http://boxesandarrows.com/connectors-for-dashboards-and-portals/#comment-6824 @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!

]]> By: joelamantia http://boxesandarrows.com/connectors-for-dashboards-and-portals/#comment-6825 joelamantia Wed, 30 Nov -0001 00:00:00 +0000 http://boxesandarrows.com/connectors-for-dashboards-and-portals/#comment-6825 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

]]>