Oracle—Have you no shame?
Oracle Corporation takes its name from the treasured advice-givers of ancient Greece. Its name is ironic at times, however, when its advice is far from sage. When it comes to data visualization, and dashboard design in particular, Oracle gives some downright awful advice.
I received an email from one of my readers who uses Oracle’s OBIEE tool to develop applications for his customers. He attached the following graph as an example of what Oracle teaches people when they attend the online course “Oracle BI Enterprise Edition – Build Good Dashboards”:

Based on this graph, I’m guessing that Oracle now outsources the development of its courses to the primate house of the local zoo. Although I haven’t seen the course myself, I’m told that this graph is typical. If this is what a leading Business Intelligence software vendor considers an effective way to display data, it’s no wonder that people are frustrated with the industry.
Almost every aspect of this graph fails miserably.
- It has been complicated by a 3-D rendering of the plot area and the bars (or tubes in this case), which does nothing but make it harder to interpret the values. Notice that the quantitative scale for “Dollars” and “Year Ago Dollars” on the left axis is aligned with the front of the graph, but the scale for “Forecasted Dollars” and “Forecasted units” on the right is aligned with the back of the graph.
- I assume that the quantitative scale on the left is for dollars and the one on the right is for units. If this is the case, however, the title that appears on the right-“Forecasted Dollars, Forecasted Units”-is incorrect.
- A dual-scaled graph—one quantitative scale on the left for dollars and one on the right for units—should usually be avoided, especially on dashboards, because it can be confusing and misleading. For example, notice that the forecasted units line intersects the dollars’ bars, which would naturally incline anyone viewing the graph to compare their magnitudes, yet this would be entirely meaningless, because magnitude comparisons can’t be made between them when they have entirely different scales and units of measure.
- Forecasted units would not be useful on this graph without including actual units, which has apparently been forgotten.
- Lines representing “Forecasted Dollars” and “Forecasted Units” have been used to connect values per region, which makes no sense. The patterns formed by the lines are completely arbitrary and could be changed by sorting the regions in a different order.
- The lines have large, clutter-inducing data points along them.
- The lines appear to have some sort of drop shadow or lighting effect, which makes it look as if there are four lines rather than two.
- “Dollars” for the current year and “Year Ago Dollars” are meant to be compared, not summed. By using stacked bars rather than placing separate bars side by side for the current year’s dollars and the previous year’s dollars, the comparison is difficult to make. The bars as a whole, consisting of both years stacked on one another, represent a sum that is useless in this situation.
- Given the fact that the X-axis has the title “Region”, there is no reason to clutter the graph by including “REGION” in each of the labels.
- The prominent vertical grid lines that separate the regions are unnecessary, resulting in clutter.
- The tick marks along both vertical axes are unnecessary, because gridlines appear in the graph at the same positions.
- The minor tick marks on the right-hand vertical axes are darker than the major tick marks.
- The positions of the two Y-axis titles are inconsistent, resulting in a sloppy appearance.
It is as if the person who created this “Good Dashboards” example of a graph did everything possible to make it as ineffective as possible.
How can a vendor that claims to understand data and presumes to teach people best practices in its use know so little? Oracle, you should be embarrassed.
Take care,
20 Comments on “Oracle—Have you no shame?”
Great post. It must be shocking to know how many of these examples are being thrown around daily. For what it’s worth, we are already implementing some of your great feedback on our own software. Keep up the great work. Robert
Even more discouraging is the lack of awareness that exists within the DW/BI developer community. For the most part they are simply not aware of what is good and bad regarding data visualization.
However, when they see it and someone can explain why it’s good, most are genuinely interested…but lacking in the follow-through.
Thanks for this great post. I have seen the same type of curiously-named axes in Cognos when the default values and labels for a chart are kept after data items to be plotted are dragged onto the chart. At the very least, BI developers should review their work to ensure that the labels and axes make sense and communicate what is intended!
On a more positive note, Steven, your blog and your books have been instrumental in helping me and my team develop effective visualizations, even if the tools we use are not perfect!
As a user and receiver of corporate data with Oracle I would have to say this is/was/still is pretty standard.
It amazes me that in the world of 2.0 that Oracle have not cloud sourced a graphical rendering partner to develop online dashboards with decent graphics that provide what users want.
Decent reporting with all of the points noted above by Steve.
With our reporting tools we make sure there is no eye-ball bleeds by using simple design principles and quality data methodology.
I think that they have no choice but to take your post very seriously and enhance their capabilities with their BI tool set(s).
Thank you for the post!
Stephen,
I was amazed by this, and agree with your analysis, however I think the secondary (right) y-axis may be more seriously flawed than you assume: the magnitudes representing dollars for the forecast dollars series and units for the forecast units series.
The forecasted dollars should be on the primary (left) axis, but the stacking of the dollar amounts means that the series to which it relates (this year’s dollars) has been shifted up.
Plotting the forecasted dollars as a line against the primary axis would lead to a comparison between last year and forecast.
Moving the forecasted dollars to the secondary axis, which is at twice the scale, appears to be an attempt to overcome the problem created by stacking the bars, but as you point out creates more problems than it solves. By doubling the scale of the forecast dollars it becomes roughly the same magnitude as the top of the stacked bars [2 x ~= + ].
This, though, introduces another problem: the units scale become overly stretched, making the units appear very flat and hampering interpolation.
If, as you suggest, the three dollar series were plotted on a common y-axis (ranging from 0-200, say) interpolation of all three series would be easier. If there really was a need to add the unit series, the secondary axis could then range from 0-80, allowing better interpolation of the units.
It looks to me as if one error (stacking the bars) has led to another (plotting the forecast dollars at double scale) and another (plotting the units on too broad a range).
I would have thought that small multiples (bar chart per region) showing dollars, prior year and forecast might be the best way out, keeping the units to a separate graph.
A bullet graph per region might be another alternative,
Rob
Stephen,
you are right: this is probably the worst graph I’ve ever seen. Thanks for this great post.
I took the graph and transformed it in the several steps into a good-looking chart. Have a look at this Excel 2003-sheet: http://bit.ly/aeK6PA
I wrote about it on http://openbi.info – in german, sorry!
the best, Lars
This would look fantastic embedded in a PowerPoint slide.
Jim,
I usually use PowerPoint to present and print my charts/Dashboards. It’s easy with the excel camera – a nice, but well hidden feature of excel: just link a range of excel in a PowerPoint slide.
Lars
And to think that Oracle provides Tableau in an OEM software stack called Oracle Visual Explorer (OVE) as a result of the acquisition of Hyperion. Last word was that OVE was restricted to financial applications only so the sales folks cannot use it to remedy the clutter in Steve’s post.
Stephen, I’ve not been here for a while. I have to come more often. This is a lovely piece of work; it shows how easy it is to misuse features. But it’s disappointing if this is how trainers teach the use of those features – how to cram them in rather than using them to achieve clarity.
Keep showing the way.
Merv
Steve,
I agree 100%. Thanks for taking the time teach by (wretched) example.
-NR
Reporting is often considered to be the easiest part of Business Intelligence, but the truth is that there are infinite possibilities of producing wrong and misleading reports.
To make things worse, many times these reports look great at first sight.
Thanks for a very good example
Andrea
Back in the days when I was a consultant (5 weeks ago…) I used to give a taster session to public sector clients on ‘information design’, piggy backing entirely on the work of Tufte, Few etc.. Thank you!
I found that the people who ‘got it’ (let’s call them Type 1s) were the ones who had sufficient understanding of their business to know that there are some questions that need answering with more than just words — and they knew underlying dynamic of their business was complex and any help with the interpretation would be a boon.
The others (Type 2s) attending would besmiley and interested. But within weeks, they’d go back to using Excel as graph paper, with silly charts and bad tables (though with fewer colours and pie charts…). They would still be enamoured by glitzy ‘infographics’, fooled by glamour rather than information — but then, they don’t deal with information the same way as the type 1s do.
The hard bit of a good design is knowing what you want the graphic to say — without that any kind of design just flounders. And knowing what you want it to say requires an ability to interpret the information.
There are a lot more Type 2s than Type 1s in the world. The BI guys are doing exactly the right thing for the Type 2s — there’s more money there. I’m still waiting for a simple tool to create sensible charts.
Hi Stephen,
I took an Oracle OBIEE course 2 years ago and they actually mentioned your books as extra info to learn about presentation and display, while getting students to make 3D charts and add shading to charts and descriptions.
It’s obvious that the tools were built by IT folks and the examples by Marketing, without ever getting near an end user or visualisation expert. At least it wasn’t a pie chart ;-)
Thanks for this post and keeping us all updated on the dos and do not dos!
Iain
Thank you!
There’s nothing like a good example that’s been so thoroughly dissected.
Your work is a gift to us all.
Brenda
Communications Consultant
Málaga, Spain
As an aside, earlier in the year I tried to replicate some of your microcharts in Oracle’s BIEE and was reasonably successful, but have never been able to productionise this work due to unpredictable runtime layout/formatting issues i.e. If the column heading of a table is wrapped the sparklines on the LHS will no longer line up with the categories they represent in the table. The good news is that I saw a demo this week where they had been rendered using google charts and because they are rendered inside table cells I’m optimistic that the formatting issues I mention above will not occur. You have to jump through some hoops in terms of providing the dataset as you are building them from primitive line and bar charts, but it is not too complex and a repeatable design pattern. The bad news is that it does not look like the next imminent release of OBIEE will include these chart types natively.
Having worked at Oracle on and off over the last 20 years, I’d have to say that Oracle in general is not in the business or even interested in the business of data visualization. Visualization, you’d think, would be right down Larry’s alley with Steve Jobs being, or at least at one time, one of his best industry friends. It’s sad to me. I love visualization graphics and helped improve quantitative visualization in OEM with the database performance pages: OEM 10g Performance pages before and after
That is in fact sad to hear. I recently sat through a 1 hour demo of what is likely to be in OBIEE 11g, the next imminent release. There was an interesting part where the Product Manager flashed up what looked like a bar/line chart combo and said “and now we have sparklines”. It happened so quickly that all I could think was “They don’t look like Sparklines to me”. The next day I was sat next to one of the Product Manager’s staff and asked to see them. He knowingly looked across and said “We don’t have sparklines”. So the interesting point is that clearly Stephen’s ideas have pricked Oracle’s conscious but not to the point that they feel compelled to do anything about it! Either that or they are redefining what a sparkline is!
As an aside, earlier in the year I tried to replicate some of your microcharts in Oracle’s BIEE and was reasonably successful, but have never been able to productionise this work due to unpredictable runtime layout/formatting issues i.e. If the column heading of a table is wrapped the sparklines on the LHS will no longer line up with the categories they represent in the table. The good news is that I saw a demo this week where they had been rendered using google charts and because they are rendered inside table cells I’m optimistic that the formatting issues I mention above will not occur. You have to jump through some hoops in terms of providing the dataset as you are building them from primitive line and bar charts, but it is not too complex and a repeatable design pattern. The bad news is that it does not look like the next imminent release of OBIEE will include these chart types natively.
Sparkcharts are part of Oracle’s Application Development Framework http://download.oracle.com/docs/cd/E14571_01/web.1111/b31973/dv_intro.htm#BHCHCIEF (not yet OBIEE) and in my opinion come with a very nice set of features including inline sparkchars.