A balance needs to be achieved; It's as wrong to focus only on eye-candy as is to build a too technical dashboard for users that will feel scared about it.
At Webdetails we've been getting very interesting conclusions from the projects we have with our clients, namely the Mozilla Metrics project, where we're implementing a full scale Dashboard centric Pentaho implementation.
Side note: maybe it's just our experience, but our clients have been much interested in dashboard centric projects; All of them make extended use of CDF in it's standalone mode (that is, without the user console). The user console has been used more to specific usage rather than the common use. This is the main reason that makes us develop and extend CDF.
On the Mozilla metrics project we started with specific by-subject analysis and then evolved to a set of summary dashboards that allow dynamic drilling, slicing, focus and allow the users to get to any information they want visually, optionally getting the raw numbers with a single click.
Recently we've reached an interesting conclusion; as much as we can develop a full-featured all-in-one dashboard, some users may feel more comfortable with dashboards that show less information but more context; We've learned that, when designing dashboards, we should focus on users first and data next.
So this is the way CDF is evolving now:
- Increase usability - Make users feel more comfortable
- Increase development speed
We're currently giving our first steps in the first one, and till the end of this month we'll be working hard on this 2 subjects, hopefully trying to nail both of them at the same time - let's see if we can make it.

Our first stab into the first goal is extending charting functionality, allowing users to do perform certain operations while giving it some eye-candy. The picture above shows a typical bar-chart generated by the jFreeChart CDF component; A lot of
people in the pentaho community don't like this rendering engine a lot; while it's true that it doesn't look that good, the truth is that open flash charts is not a very matured library and we miss some core functionalities.
For the record, we're also working on a OFC CDF component; our objective is to get to a CDF component that is independent of the rendering engine - jfreechart, OFC, libsparklines, flot, whatever. But this requires a big leveraging effort in order to maintain the core functionality we expect from dashboard components.
Anyway, back to the subject; When we make a bar chart plot like the above one, there are clearly some type of operations that can be done regardless of the data displayed: get the details, looking at the data, etc. So we implemented a set of (extensible) operation that we can access while doing a mouse hover:

So far, we've implemented data details, zoom, export to excel and CSV and switch to bar/pie view, but we can make this list grow/change as desired.
This an example of exporting the data to excel regardless of the data source - MDX or SQL



Pedro,
ReplyDeleteI like the export option. are you rerunning the xactions or have you saved the result sets separately?
Hello there.
ReplyDeleteWe run it again server side. Saving result sets in memory isn't an acceptable approach. Since dashboards have to render fast anyway, performance should not be a problem
GREAT work Pedro! Wonderful user focused enhancement; customers I'm sure will be appreciative. Pentaho needs as many voices/customer driven enhancements so this, like most of the CDF be a big win for customers.
ReplyDelete