Monthly Archives: April 2012

Effective Visual Design – How Important is it for dashboards ?

I have been having a discussion with Andreas Schneider in the comments section of my recent Xcelsius, Zen and Nirvana blog post, but I think the topic we’ve been discussing “effective visual design” is important enough that this discussion warrants a post of its own.

At issue is Andreas’s comment that the “most important task” in building a dashboard is “effective visual design”. The reason that I question this is that in some quarters “effective visual design” becomes an almost fanatical pursuit, which IMO goes beyond its value and in some cases becomes counterproductive. My comment back to Andreas was:

“I am not sure why you feel ‘effective visual design’ is so important, I agree that it is important to make sure that visual design does not lead to incorrect interpretation of the data, but past that the difference it makes feels marginal. Happy to be proved wrong if you have good examples to the contrary.”

Before anyone starts yelling at me, I want to be clear:

  1. I absolutely think that the visual design of a dashboard can make a difference
  2. We need to be sure that visual design never leads to incorrect interpretations of the data
  3. Research and thinking in this area, over the years, has led to many improvements in the way dashboards and visualizations are delivered

But:

  1. Over-focus on visual design marginalizes other, potentially more important aspects of a dashboard
  2. Particularly, supposedly “unbreakable” rules of visual design need to be viewed in the context of the purpose of specific dashboards
  3. The speed at which people pick numbers out of a dashboard seems to me to be of fairly low importance and so any visual design with this sole purpose is unlikely to be that valuable

In his response to my question, Andreas mentions a number of interesting things, but probably most interesting was:

“Apple was/is so successful, because of the thoughtful design down to the last screw, down to the last mouse-click”

I would strongly argue that Apple’s design is more about engagement than efficiency. I know they do lots of usability testing and their products are known for ease of use, but from a consumer perspective it seems to me that their success depends more on the fact that their products are beautiful (dare I say “sexy”) than that they are efficient. I am sure there is a more efficient layout of the iOS home screen (perhaps with muted colours) but I doubt it would be more engaging.

Another obvious example is the fact that reflective glare on iOS app icons is mandatory. In one of his white papers, Stephen Few says “When we encounter glare in the real world, we find it annoying, so what possible purpose could it serve on a computer display?” From an efficiency perspective, he is absolutely right, but that rather overlooks the engagement perspective.

One of the key issues which has faced BI for years is user adoption; dashboards are no different. I have no idea why people like glare on dashboard objects, it makes no sense (even though I like it myself), but the fact is they do, it draws them in, it engages, it drives adoption; and, if you ignore that effect then you immediately tie one hand behind your back in terms of making your dashboard project a success.

The lesson we in the dashboard world can learn from this is summarized in the trivial formula:

Total value of a dashboard = number of views x average value per view.

Efficient design can drive the second half of this equation (i.e. average value per view) but we need to understand that it can come at a cost to the first half (number of views).

We see this effect every day when we browse the Web. If we come across a site which looks bad then we tend to leave before even before we try it. It could be the easiest site in the world to use, but it may never get a chance because of its initial appearance.

This is one of the reasons I asked Andreas for examples of the real business difference he has seen effective design make. If we have real examples we can start to weigh up their value against the value of doing potentially less efficient things which might drive increased usage of dashboards.

Unfortunately, Andreas did not offer any specific examples, but he did include a list of what he considers to be good and bad design:

“3d charts or even worse, stacked 3d pie charts, bright colors for almost everything, drawing boxes around charts to separate data visually, or segregating data by splitting data up across multiple screens (thereby hindering pattern search, etc.) are all examples of poor visual design. Gauges, which use lots of real estate, but do not provide much information are another example of poor design choice.

Good design choices: use line charts for time series as a rule of thumb, do color encode your KPIs (not blue for Revenue in one chart and then yellow for Revenue in another slide for the same KPI e.g.), create context (rich information), allow for comparisons.”

To be fair, in general these (particularly the good design choices) seem sensible, however, I do think that we should be cautious labelling bright colours, gauges and multiple screens as poor, without any further context or thought about the purpose of a specific dashboard.

One thing which always strikes me as odd in these discussions about efficient design is the focus on speed of interpretation, and Andreas raises this again when he says effienct visual deisng is good because:

“Because it allows us to see and understand the presented data quickly”

Most dashboards I have seen (however inefficiently designed) take a few seconds at most to assimilate; is cutting this from a few seconds to a fraction of a second really going to make that much difference? Again, I would love to hear of real-world examples where this matters.

Finally there is a point on which Andreas and I absolutely agree. He talks about dashboards leading:

“to understanding, which leads to action”

The important word here is action. In the words of the Gartner Analyst Andreas Bitterer “BI is not there to let you know, it is there to let you act”. However, I would argue that understanding the business context of a dashboard and how it will be used is many, many times more important in this regard than any visual design.

 

Moving Xcelsius components using the cursor keys (or not)

UPDATE : Zahid Yener just posted an update on SCN to say that rather than clicking on the canvas you can just select a component and hit the tab key, which is much easier.

——————–

When I design a dashboard with Xcelsius / SAP BusinessObjects Dashboards, I find it impossible to fine tune the layout without using the cursor keys. As a result, I find it maddening when (seemingly at random) these cursor keys stop working for positioning Xcelsius components and almost as maddening when they (again seemingly at random) start working again.

It turns out that this is all to do with focus and the canvas. If you Alt-Tab (or use some other method) to switch windows and take focus away from Xcelsius, when you return you are left in a state where the canvas no longer has focus (at least in terms of being able to process cursor key presses). If you click on a component then the canvas still does not have the right focus, so when you press a cursor key, the component doesn’t move.

To resolve this, you need to click on the canvas itself (note: if you have a backdrop image or another component covering the whole canvas then you will have to move it as you need to click on the canvas itself). Once you have clicked on the canvas, you can then happily select any of the components and move it with the cursor keys … until, of course, you switch away from Xcelsius again, when you will need to go through this procedure again!

 

Xcelsius, Zen and Nirvana

Yesterday SAP held a new style “All Access” webinar to discuss its recently published Statement of Direction (SOD) for dashboard development. The openness of the format (indeed the fact the event happened at all) was a testament to Mico Yuk’s persistence and plaudits should go to her and to Mani Gill, Scott Leaver, Ian Mayor and Jason Rose from SAP, who were on the call.

It was an interesting call with many key points to take away and although it probably didn’t answer everyone’s questions I think the folks did a good job. Answering detailed questions from users of a product, looking out over 3-5 years, in a public webinar, which competitors could easily be listening in to, is a careful balancing act which does not always satisfy everyone. I have sat in that chair many times and would like to congratulate Mani for the way he handled things yesterday (disclosure, I worked with Mani at Crystal and Business Objects for many years).

Key points from the SAP SOD and “All Access” call

The main news from both the call and the SOD was that, for the time being (the next two years in my estimation), SAP will have a dual-track of dashboard technology, comprising a new product codenamed Zen and the existing SAP BusinessObjects Dashboards (formerly Xcelsius) product. What I took away from the call is that, over this dual-track timeframe:

1) For dashboards not connected to BW, Xcelsius/SAP BusinessObjects Dashboards (SBOD) is the appropriate tool

2) For the next 6-12 months, BW connected dashboards should continue to use Xcelsius / SBOD

3) In 6-12 months’ time, following its release, Zen should be considered for BW connected dashboards

To address the “Xcelsius on mobile devices” issue, the SAP folks reiterated the “export to HTML5″ plan which Scott Leaver announced at BI2012 (summarized in a previous blog post here ) and Mani confirmed again that investment in Xcelsius is on-going and improvements (particularly in the mobile arena) are planned after the HTML5 version is released.

3 challenges facing mobile BI projects

The dates for the HTML5 version of Xcelsius were confirmed as “before the end of the year” (although I am still not clear if this is beta or ramp-up). In the interim, for Xcelsius mobility, Mani was kind enough to specifically call out Antivia (XWIS Anywhere) as one of the partner solutions which would bridge the gap (I think he said it on the call, but he certainly tweeted it afterwards).

Is SAP going all Zen on us?

Zen, it turns out, is a completely new tool coming out of the “Analysis” team in Europe; it sounds like it started life as a front-end tool for BW, but is now being re-positioned, over the long term, as an application development tool aimed at professional developers (i.e. people who write code) and as a dashboard design tool.

You might wonder how an app development tool can also be a dashboard design tool, but this isn’t as much of a stretch as it seems. As I have written before, there is an convergence between dashboards and BI Applications happening today in the marketplace (see my recent blog post here and SCN Article here and the On-demand Webinar here). The re-positioning of Zen is, IMO, just part of that convergence.

As for the idea of a professional coding environment for building Dashboards/ BI Apps, it would be hard for us to disagree given we launched one of these last October at SBOUC in Orlando. It is a tool called FlexWIS and you can find more details here and see it in action in a video here.

Ian Mayor (the solution manager for Zen) reiterated that Zen is initially targeted only at BW and HANA, but would be broadened out (through the semantic layer) to other sources over time. This broadening is planned for the third phase of the roll out (phase 1 is later this year) and this is why I think that the two tracks (Zen and Xcelsius) will stay completely independent for at least the next two years.

And, what future for Xcelsius?

That brings us onto the $64,000 question: “How will these two tools relate to each other in the long term?” or in the rather pessimistic way that existing users insist on putting it “does Zen mean the death of Xcelsius?”.

Actually, in my view it is not that big a question, there is a lot of runway in front of Xcelsius. It is the world’s most widely deployed dashboarding tool (with the possible exception of Excel) and at a conservative estimate had netted SAP Business Objects over half a billion dollars in direct licence revenue over the years (and much more in influenced sales). It is not going away anytime soon. Mani was quick to point out that Xcelsius is “not another DeskI” but even if it was, history suggests that deprecation would be some 5-10 years from now.

However, I don’t think it will come to that. Either Zen will become a great Xcelsius replacement or Xcelsius (with HTML5 and on-going improvements) will continue well into the future – there is just too much value in the Xcelsius concept to let it go.

A rose by any other name would smell as sweet

… and, so the principle of Xcelsius re-executed in Zen, with suitable conversion tools (and friendly upgrade licencing), could be the right path for the future.

Having said that, there is a key point here: Zen is currently targeted at developers. The key innovation in Xcelsius was the integration of the spreadsheet. I can’t put it any better than Jamie Oswald did on last night’s DS Layer podcast (here)

“the power of Xcelsius was that you could build applications but do it without needing people who were application developers

That was made possible by the integration of the spreadsheet. If this key innovation does not live on somewhere in the SAP product set, then I would see that as a huge opportunity for an enterprising start-up to walk in and take up the mantle.

But, I don’t expect this to happen, there is too much investment in Xcelsius in the SAP user base, and it is too good a tool for allowing non-developers to create the new breed of BI Applications, for SAP to throw this innovative baby out with the Flash bathwater.

 

Introducing XComponents for SAP BusinessObjects BI 4.0 FP3 beta-program

The XComponents are probably the worlds most downloaded extension components for SAP BusinessObjects Dashboards and Xcelsius, with well over 10,000 downloads to date and they are used in some of the world’s largest Xcelsius projects by some of the largest companies in the world.

With BI 4 FP3, SAP have updated the version of the Flex SDK that they embed inside SAP BusinessObjects Dashboards, which requires all third party components, including the XComponents, to be re-worked to use Flex 4.

I’m delighted to say that we’ve already undertaken this piece of work, so the XComponents are now BI4.0 FP3 ready and we’ll be running a beta-program for the updated XComponents to coincide with SAP’s own ramp-up program for BI4.0 FP3. By joining our beta program you will be able to:

  • Create new dashboards in BI4.0 FP3 that use the XComponents
  • Convert some of your existing XComponents based dashboards to the new Flex 4 world to ensure they behave as expected
  • Help us to identify and fix any small niggles that have crept through our testing process

The BI4 FP3 compatible XComponents should be identical to their pre-FP3 counterparts (part of the beta program is to test this). The only difference is that XYahooMaps has been removed from the package as Yahoo have withdrawn the mapping service on which it depends. However all the other XComponents are there including:

  • XProgressImage
  • XReflector
  • XScorecard
  • XTree
  • XReflector
  • XSparkline
  • XBulletchart
  • XGlobe
  • XHarveyBalls

If you are part of the SAP BusinessObjects BI4.0 FP3 ramp-up program and you would like to join the XComponents beta program please register here.

Please note: This beta version of the XComponents only works with SAP BusinessObjects BI4.0 FP3 and upwards. If you are running an earlier version of SAP BusinessObjects Dashboards / Xcelsius, please continue to use the existing GA version of XComponents