How to improve your Business Objects charts

disaster, disguised as a "dashboard"

disaster, disguised as a “dashboard”

Business Objects, SAP’s BI platform, is notoriously bad for data visualization. Somehow, it empowers the developers to make all the wrong decisions at the same time and create really ugly and unusable “dashboards”.

Lately, I’ve seen my share of ugly bobip visualizations, like the one above. Which would seem ok but it commits the greatest of sins: unnecessary embellishment.

To create better Business Objects visualizations you should try to avoid “non data ink”, like:

  • Unnecessary big numbers (100,000,000 could be abbreviated to 100M)
  • Axis borders.
  • Colored or gradient backgrounds.

Also, you could re-work your charts to remove:

  • Data point markers.
  • Double vertical axis.

Also, surprisingly –or not– Business Objects lets you mix bars and lines to confuse the reader:

188

Lines in a chart are supposed to express continuity, cause and effect.

In this case, the use of lines confuses the reader. There’s no logic in stating that a measurement in the leftmost products influences the ones at the right.

Unless you have a time measurement in the horizontal axis, you should avoid using lines mixed with bars.

All this omissions and mistakes defies the purpose of the chart, which is to give a quick assessment of the situation. A professional product like Business Objects shouldn’t let you make those mistakes. But unfortunately it does and that’s why your charts suck.

Noah Iliinsky addresses some of this charting “sins” in his famous talk “Data Viz: You’re Doin’ it Wrong”

I don’t doubt for a second that SAP’s BI Platform must be great for building data warehouses, but it’s notoriously poor as a tool for visualizing data. You would be better served by using bobip in the back-end and disguising it with Processing, D3js or some other library to better show of the fruits of your hard work. In every Business Intelligence endeavor, charts are the visible face of the project. If your charts suck, your project sucks. Is as easy as that.

As a developer, it also helps to learn some design elements and even do some reading on the subject. Remember: your charts and dashboard should be compelling enough to inspire and motivate the users to dive into the data.

 

How to present statistics without boring your audience

boring_lecture

A few days ago I found a very valuable, yet free resource for improving the way we report statistics.

Making Data Meaningful is a series of short, sweet and free ebooks created by the United Nations Economic Commission for Europe as a practical tool to improve the way charts, tables and statistical data are presented to the general public.

Don’t be deterred by the official designed-by-committee air that a UN publication may have, this are books inspired by the latest trends on mass communications and data visualization. In it you will find several references to some of my favorite books: Few’s “Show Me The Numbers” and Tufte’s “The Visual Display of Quantitative Information”.

I particularly like Part 1, “A guide to writing stories about numbers“, because in a very concise manner, it proposes a way of changing your approach to presenting statistics. Starting from the language. Look at this wonderful summary:

Use:

  • Language that people understand;
  • Short sentences, short paragraphs;
  • One main idea per paragraph;
  • Subheadings to guide the reader’s eye;
  • Simple language: “Get,” not “acquire.” “About,” not “approximately.” “Same,” not “identical”;
  • Bulleted lists for easy scanning;
  • A good editor. Go beyond Spell-Check; ask a colleague to read your article;
  • Active voice. “We found that…” Not: “It was found that….”;
  • Numbers in a consistent fashion: For example, choose 20 or twenty, and stick with your choice;
  • Rounded numbers (both long decimals and big numbers);
  • Embedded quotes (these are sentences that generally explain “how” or “why”,
  • and which journalists like to use verbatim in their news stories in quotes);
  • URLs, or electronic links, to provide your reader with a full report containing further information.

Avoid:

  • “Elevator statistics”: This went up, this went down, this went up;
  • argon and technical terms;
  • Acronyms;
  • All capital letters and all italics: Mixed upper and lower case is easier to read;
  • “Table reading”, that is, describing every cell of a complex table in your text.

 

And then, they present several ways on how you could improve your writing skills:

Not Good:
From January to August, the total square metres of utility floor space building starts rose by 20.5% from the January to August period last year.

Better:
In the first eight months of 2004, the amount of utility floor space started was about 20% higher than in the same period of 2003.

 

Also, another wonderful summary about creating better charts:

  • Achieve clarity in your graphics by:
  • Using solids rather than patterns for line styles and fills;
  • Avoiding data point markers on line graphs;
  • Using data values on a graph only if they don’t interfere with the reader’s ability to see the big picture;
  • Starting the Y axis scale at zero;
  • Using only one unit of measurement per graphic;
  • Using two-dimensional designs for two-dimensional data;
  • Making all text on the graph easy to understand;
    • Not using abbreviations;
    • Avoiding acronyms;
    • Writing labels from left to right;
    • Using proper grammar;
    • Avoiding legends except on maps.

 

Few people stop to think about how others will interpret or read their findings. Others are delusional enough that they deliberately stay away from this “journalistic style” and think that numbers speak for themselves. That’s rarely the case.

Even if you have a chart that tries to explain the numbers, you still have to put up some work to make those statistics interesting enough so that they stand out and you don’t bore or confuse your audience. You have to tell a compelling story, you have to incite curiosity, questioning and further exploration. Even if you’re doing a private report, you have to be a journalist and a storyteller.

So if you want a quick crash course on the subject, go on the UNECE website, download Making Data Meaningful and give it a read.

 

Drawing the world by hand

At Lucerne’s Gletschergarten, among old maps, models and reliefs of the Swiss Alps, we’ll find an expo from Ueli Läuppi, a local cartographer that makes hand drawings and colorings of maps using a particular projection that highlights a thorough representation of the mountains.

Moreover, Läuppi has moved his studio to the museum and on certain days you can actually see him completing a precipitation map from an Asian region using a rapidograph and a box with carefully labeled Caran d’Ache color pencils to differentiate rainfall ranges.

Läuppi’s work is at he crossroads between science and art. His extensive research (documented on video) evidences his background as an engineer, and his will power to temporarily move his studio to the museum borders on performance art.  It’s also evident that Läuppi knows a thing or two about visualization. His maps are very eloquent when it comes to representing data and explaining their meaning.

Personally, I consider that the staging of this desk in the middle of the exhibition with the rest of the unfinished pieces sends a message: maps are made by people and it’s hard to draw maps.

All of this reminded me of a post about the wireframes and skeletons for web apps and pages and the opinions of some experts who believe presenting sketches instead of perfect lines gives your output a “work in progress” feeling, opening the doors for engagement and getting better and more timely feedback from your clients.

 

In Sketchy Rendering for Information Visualization, Jo Wood, Petra Isenber, Tobias Isenberg, Jason Dykes, Nadia Boukhelifa and Aidan Slingsby, propose drawing visualizations as if they were made with a marker on a board, in order to communicate that the design is not complete, that is open to criticism and changes, and that visualizations and dashboards represent a narrative in progress. Also, unlike architectural drawings or industrial designs, graphics don’t represent tangible objects, so they don’t need to be accurate. Their goal is to help tell a story. Just as the proverbial business plan written in a napkin, graphics with sketches aim to illustrate a point and it’s ok to sacrifice some accuracy.

The imprecision suggested by sketchy features may reinforce perceptions of simplicity and thus reduce the expectation of cognitive effort required to interpret the visual scene

As part of the method illustrated on paper, authors have created a free library to be used with Processing that provides astonishing results:

They seem hand-drawn, right?

And maybe there’s another key: just as with Läuppi’s maps, these graphics convey the idea that visualization was thought out and made by a human and that there’s meticulous work behind them.

A Handsome Atlas gathers visualizations completed at the end of the XIX century for the US census. These are graphics of great beauty, charts that tell a story and that are truly different from the automatic output done on excel.

We forget that graphics need to be well-thought; that they should communicate something, be memorable and situate themselves between art and science.  And although a computer does the rendering job on the screen, when visualizing data we’re also drawing the world by hand.

Läuppi’s expo will be displayed at the Glacier Garden until September 15th of 2013.

 

Sparklines and datawords

11_sparklines

We have seen a lot of sparklines over the last few years. They’re one of the most used high-density charts out there and, if applied properly, they can be a killer feature of any dashboard or report.

The sheer amount of information that can be condensed into sparklines makes them a viable resource to provide a quick at-a-glance story of the evolution of a measurement.The best are the ones which provide additional context, like the normal range, filled with gray in the following charts:

sparklines

But it wasn’t until I read Beautiful Evidence by sparklines inventor Edward Tufte, that I discovered that these charts were originally designed to be inserted within a text. Becoming datawords, a beautiful term:

dataword

 
If they’re not abused, datawords can be extremely helpful to illustrate points made in the text.

This reminded me of the explorable explanations and reactive documents by Bret Victor. A very clever way of inserting what-if explorations within a text. Test it below by clicking and dragging over the number of cookies:

 

When you eat cookies, you consume calories. That's % of your recommended daily calories.

 

I think datawords and explorable explanations (explorable datawords?) go together quite nicely. Don’t you?

 

Resources:

Beautiful Evidence also provides some tips on the correct usage of sparklines. Some of those examples can be found in this page.

Some tips samples on how to create and use sparklines in Excel. More samples here.

Tangle, a javascript framework for creating reactive documents.

jQuery plugin to create sparklines

 

How to create a dashboard

Consider the dashboard of a car: in it, the driver can see the most important data: speed, RPM, mileage, etc. The dashboard displays decision-making information, in a graphical manner, in a single place.

The information dashboards should comply with the same requirements:


Although not necessarily copying the model of a car! This is a mistake. There are better ways to graphically display information.

CIO Dashboard, a Stephen Few classic

So, we take a few charts, some tables and we throw them all together in one screen, right?

Uh… nope.

 

What makes a good dashboard?

  • It contains the requested information (obvious? Not always!)
  • It has readable text with high contrast (black over white, or some other light shading).
  • It highlights the key information.
    • Charts are easy to find.
    • The problems are marked with icons or in bold letters.
    • The important information is generally at the upper left or lower right side.
  • It has no more than 5 or 6 data containers.
  • It displays useful data to make decisions.
    • Comparisons against goals, previously set standards or historical data.
  • It doesn’t require vertical or horizontal scrolling. All the information is shown in the same screen.
    • If you have a lot of information, you can use tabs.
    • If you must, use multiple screens. But remember: the key is to keep all the data related to each other in the same screen.
  • Its graphics have a high data/ink ratio without chartjunk.
  • It displays the right charts according to the type of data.
  • What seems interactive, is interactive. The charts offer details and drill-down when you click on them.

But I think the most important thing is that the dashboard tells a story, or helps you tell a story and, above all else, is esthetically simple. No color degradations or images with shading or use of 3D. Imagine for a second that your car displayed your speed with a 3D chart, would you be able to read it so easily? Would you be able to make right decisions? I don’t think so. Have that in mind when designing a dashboard.

Inspiration

At Excelcharts you can get various dashboard examples made in excel. If you need a little more spiritual aid, I recommend Information Dashboard Design, de Stephen Few.  A short and easy to read book; ruthless when it comes to tearing down old notions and clear when teaching the principles of good design for dashboards and reports in general.

Although it has some things specific to their product, the Tableau Visual Guidebook is an excellent guide on the basics of producing a good data visualization. The last pages contain a great checklist that you should complete before deploying your visualization.