Category Archives: Programming

4 Best Practices to make your Storyboards more Dynamic and Appealing

By Iver van de Zand  – Business Intelligence & Analytics – SAP – Visualization – DataViz – Evangelist – Author of “Passionate On Analytics”

Your end users will love it when you’d deliver your story- and dashboards in a more appealing and dynamic way. In these Let Me Guide series I discuss 4 easy to use best practices that will help you doing so:

  1. Using backgrounds

  2. Using Navigation

  3. dynamic Vector Diagram pictures: SVG

  4. Dynamic Text

Using Background

Backgrounds can better the looks and experience of story- and dashboards. Use the opacity to ensure the attention is not too much distracted from the actuals graphs and charts. I tends to create my backgrounds myself using PowerPoint: create a slide with a layout you like allocating space for KPI metrics and visualizations. Save the slide as JPG which you can import as background into SAP Lumira.

Using Navigation 

If you have story- or dashboards with multiple pages, my experience is that custom navigation buttons help you users finding what they should read. I use custom navigation all the time on my storyboard’s landing pages for example. Here is how you do it:

  •  Find a shape or picture that you want to use as clickable button and save it as xx.jpg

  • Import xx.jpg as picture in Lumira and drop it on your storyboard where you want it

  • Drag and drop a rectangle shape exactly over you newly created button and set its lines and fill-color both to “none”

  • Click you “invisible” shape and add the URL or page number to it

  • Save and preview

Example landing page B

example of navigation buttons

Example landing page A

Example landing page A

Example of a core layout of a landing page for your storyboard. The color-coded tiles can be used as navigation buttons. The generic tiles act to show key metrics info. Save the core lay-out as JPG and use this JPG as core background in your storyboard. Now add an object over the color coded sections, make it invisible and add a page-link to the appropriate page in your story.

SVG files

Especially infographics gain on weight and meaningfulness if you use dynamic pictures as part of your charts and graphs. Bar- and line charts in SAP Lumira have the possibility to change its regular column and markers into a dynamic pictogram. You can use the embedded pictograms but also add your own. The pictograms need to be in the SVG dynamic vector format. Search for pictures on Google with the “ filetype:SVG” string to find SVG’s. Save and import them to Lumira and change the graphs properties. The results are impressive. It is easy to create your own SVG files: I use PowerPoint to create my own pictures and save them to JPG. Using conversion tools easily creates an SVG that you can use as dynamic chart/graph picture in your storyboards.

Dynamic Text

Dynamic Text is a powerful way to improve context sensitive messaging in your story- and dashboards. The dynamic text is based on a dataset attributes and thus changes when data is refreshed are filtered. Since SAP Lumira handles the dynamic text as any other attribute, you can also apply formulas against the text.

Brainteaser: Storyboard or Dashboard…Self-Service or Managed…you choose

By Iver Van de Zand, SAP

If there is one term that always is food for discussion when I talk to customers, it is definitely “dashboard”. What exactly is a dashboard, how close is it to a storyboard, are dashboard only on summarized data and when to use a dashboard versus a storyboard. Tons of questions that already start in a bad shape because people have other perceptions of what a dashboard really is. And let’s be honest; take a canvas, put a few pies on it and a bar-chart, and people will already mention it as a dashboard. Let’s see whether we can fine-tune this discussion a bit.

A Dashboard

A business intelligence dashboard is a data visualization technique that displays the current status and/or historical trends of metrics and key performance indicators (KPIs) for an enterprise. Dashboards consolidate and arrange numbers, metrics and sometimes performance scorecards on a single screen. They may be tailored for a specific role and display metrics targeted for a single point of view or department. The essential features of a BI dashboard product include a customizable interface and the ability to pull real-time data from multiple sources. The latter is important since lots of people think dashboards are only on summarized data which is absolutely not the case; dashboards consolidate data which may be of the lowest grain available! Key properties of a dashboard are:

  1. Simple and communicates easily and straight

  2. Minimum distractions, since these could cause confusion

  3. Supports organized business with meaning, insights and useful data or information

  4. Applies human visual perception to visual presentation of information: colors play a significant role here

  5. Limited interactivity: filtering, sorting, what-if scenarios, drill down capabilities and sometimes some self-service features

  6. They are often “managed” in a sense that the dashboards are centrally developed by ICT, key users or a competence center, and they are consumed by the end-users

  7. Offer connectivity capabilities to other BI components for providing more detail. Often these are reports with are connected via query-parsing to the dashboards

A Storyboard

Is there a big difference between a storyboard and a dashboard? Mwah, not too much: they both focus on communicating key – consolidated – information in a highly visualized and way which ultimately leaves little room for misinterpretation. For both the same key words apply: simple, visual, minimum distraction.

The main difference between a dashboard and a storyboard is that the latter is fully interactive for the end user. The interactivity of the storyboard is reflected through capabilities for the end user to:

  • Sort

  • Filter data: include and exclude data

  • Change chart or graph types on the fly

  • Add new visualizations on the fly; store and share them

  • Drill down

  • Add or adjust calculated measures and dimensions

  • Add new data via wrangling, blending or joining

  • Adjust the full layout of the board

  • Create custom hierarchies or custom groupings

  • Allow for basic data quality improvements (rename, concatenate, upper and lower case etc)

Another big difference between dashboards and storyboards is that storyboards are self-service enabled boards meaning the end user creates them him/herself. Opposite to dashboards that are typically “managed” and as such are created centrally by ICT, key users or a BICC, and are consumed by the end user.

A Dashboard versus a Storyboard

So your question, dear reader, is “what is the day-to-day difference and what to you use when”? Well the answer is in the naming of both boards:

The purpose of a storyboard is to TELL A STORY: the user selects a certain scope of data (which might be blended upon various sources) and builds up a story around that data that provides insights in it from various perspectives. All in a governed way of course. The story is built upon various visualizations that are grouped together on the canvas of the storyboard. These visualizations can be interdependent – filtering on one affects the others – or not. The canvas is further enriched with comments, text, links or dynamic pictures … all with the purpose to complete the story.

Storyboarding has dramatically changed day-to-day business: the statement “your meeting will never be the same” applies definitely. Your meetings are now being prepared by creating a storyboard; meetings are held using storyboards to discuss on topics and make funded decisions, simulations on alternative decisions are done during the meetings using the storyboards and final conclusions can be shared via the storyboards. Governed, funded, based on real-insights!

A dashboard has a pattern of analyzing that is defined upfront. It is about KPI’s or trends of a certain domain, and you as a user consume that information. You can filter, sort or even drill down in the data, but you cannot change the core topic of data. If the KPI’s are on purchasing information, it is on purchasing information and stays like it. You neither can add data to compare it.

In a number of situations one does not want the end user to “interact” with the information since it is corporate fixed data that is shared on a frequent and consistent time. Enterprises want that information to be shared for insights in a consistent, regular and recognizable way. Users will recognize the dashboard, consume the information and – hopefully – act upon it. Think for example about weekly or monthly performance dashboards, or HR dashboards that provide insights in attrition on recurring moments in time.

Dashboards and Storyboards: the “SAP way”

The nuances made above on dashboards and storyboards are being reflected in SAP’s Business Intelligence Suite. Its component Design Studio is a definite managed dashboarding tool. Extremely capable of visualizing insights in a simple and highly attractive way while in the meantime able to have online connections to in-memory data sources, SAP BW or semantic layers. Storyboarding is offered via the on-premise SAP Lumira or via Cloud through the Cloud for Analyticscomponent.

If you have difficulties deciding what to offer to your end users, the BI Componentselection tool I made easily helps you understanding whether your users require dashboards or/and storyboards. You might want to try it.

Financial storyboard

Financial storyboard

Self-service storyboard created in around 45 minutes using SAP Lumira. On this page the heat-map section that allows for white spot analyses. Data can be exported at any time. User has numerous capabilities to add data, visualizations and additional pages

Retailing Dashboard

Financial storyboard

Financial storyboard

Self-service storyboard created in around 45 minutes using SAP Lumira. User has numerous capabilities to add data, visualizations and additional pages

Object oriented programming – by Ashith Bolar

I thought I would write few words on Object-oriented programming. Now you might ask me why I am spending my time talking about a technology that’s almost as old as computer programming itself — an idea that has an all-pervasive nature to it in the industry, there is no need to flog the dead horse one more time. Here’s the reason. I can’t tell you how many times I’ve talked to software developers and designers, who know the text-book description of OOP, but have a very limited insight into it.

When you talk to someone who dabbles with OOP, you hear polymorphism, method-overloading, dynamic-dispatch, public and private methods. But these are not what set OOP apart from its predecessors. I am in no way implying that these are not significant additions that came out of OOP. These concepts are just derivatives of the bigger idea of OOP.

Encapsulation is the primary idea behind OOP. Encapsulation simply means bundling of data and associated methods.

Let me explain: Before OOP, computer programming was a series of instructions written one below the other. This is like a two-way communication. You, the developer, is telling the computer what to do in a series of instruction. The idea goes back to the 8th century Arabic mathematician al-Khwarizmi (which is where we purportedly get the word algorithm). This is all good if you’re writing a program to determine the greated common divisor of two numbers. But over time computers have gone on to solve bigger problems, and procedural programming just doesn’t cut it.

So let’s say you’re writing a computer simulated solar system. In a purely procedural language set up, you would write a big program called “solar_system”, which controls all the planets and the sun, with a main function ‘run_solar_system()’. On the other hand, if you write a program, one that is influenced by object-oriented paradigm, it would contain encapsulations of the class of planets, with particular instates of each of the planets.

Compare the two very simplistic example codes of how each one of them looks:

Procedural paradigm:

currentPosition = getCurrentPosition('jupiter')
gravitationalField = getGravitationalField('sun')
jupiterNewPosition = 
  getNewPosition(currentPosition, gravitationalField)

Object-oriented paradigm

jupiter.calculateNextPosition(sun.gravitationalField())

Notice that in the first case, solar_system is doing the calculations for all the planets – a one way communication. In the second case, the communication is between the planet and the sun – direct communication. This code, if well written can be extended between any two (or three of four) objects within the solar system.

It is true that the expressive measure of both the paradigms is identical. What you can write in the OO paradigm could just as well be written in the procedural one. What makes the OO stand out, is its readability.

The line of code in the OO paradigm can be read as “Let Jupiter calculate its next position based on the gravitational field of the sun). Compare that to the lines of code in procedural paradigm would read something like this: “Take Jupiter’s current position, and take the gravitational field of the Sun, and using both, do some calculations and determine the next position Jupiter ought to take.”

By extension of it being readable, OO lends itself to thinking in terms of how we perceive the real world. And all this is achieved primarily by a single concept – encapsulation. By making a class called Planets, and instantiating Earth and Jupiter as Planets, the programmer has enabled the individual objects to communicate with each other, rather than letting an overarching program do all the dirty work. A clean readable code, implemented by a clean and organized underlying objects.