Design your Bullet Graphs with The Bullet Grapherator

The Bullet Grapherator now has an integrated Designer with which you can design and render your Bullet Graphs in PNG, JPEG, and SVG.

Bullet Graph Designer

Using the Designer’s Renderings tab, you can also create the Bullet Graphs in a directory of your choosing, which makes them readily available for referencing in your dashboards.

These Bullet Graphs were created during the Designer session shown above:

Designer-created PNG Bullet Graph

Designer-created JPEG Bullet Graph

Unfortunately, WordPress doesn’t allow me to upload the SVG file.

Bullet Graphs may also be saved as templates. These templates are intended to be used when the business data changes—simply:

1. load the appropriate template;
2. provide the new business data
   usually the performance and comparative measures, less frequently the qualitative ranges’ values and the upper and lower limits of the quantitative scale;
3. provide the location, name and formats of the files to create;
4. generate the Bullet Graphs

How to get it (it’s simple and easy):

The Bullet Grapherator’s site is here.
Download it from here.
Getting Started instructions on using it are here.
Instructions on using The Designer are here.

I’m interested in hearing your observations, reactions, hints, suggestions, rants, comments, or anything else.

The Bullet Grapherator is online.

After noodling around with Bullet Graphs, and being frustrated at the lack of readily available, easy to use, highly effective tools for creating them, I started an Open Source project to create just such a tool.

Announcing the Bullet Grapherator, a Java project for creating dynamic data-driven Bullet Graphs that are faithful to Stephen Few’s design.

As of this posting, the Grapherator is online and fully capable of generating SVG Bullet Graphs. It’s in its first release, and there are plenty of enhancements to make, most obviously in generating other media formats – jpeg, png, PDF, etc.

Here’s the canonical Bullet Graph created by the Grapherator:

Canonical Bullet Graph

Here’s the Java code that created it:

BulletGraphSVG bGraph = new BulletGraphSVG();
bGraph.setLabel("Revenue 2005 YTD", "(U.S. $ in thousands)");
float[] ranges = {200,250};
bGraph.setRanges(ranges);
bGraph.setLimit(300);
bGraph.setPerformance(270);
bGraph.setComparison(265);
bGraph.setScale(6);
String result = bGraph.getSVG();


I invite anyone who’s interested to please take a look and let me know what you think. Suggestions, enhancement requests, criticisms, and all other forms of civil feedback are welcome.

Bullet Graph Design: Scale Geometry and Body Alignment

The previous post explored the geometry of the Bullet Graph Body. This post explores the geometry of the Bullet Graph Scale and the alignment of the Scale’s elements with the Body and the Body’s elements.

See Bullet graph design: nomenclature for the nomenclature used in describing the Graph Body, Text Label, and Quantitative Scale.

This is the example Bullet Graph used in this exercise, copied from Stephen Few’s Bullet Graph Specification, without the Text Label:

For the purposes of this article the Scale’s elements have been rendered somewhat oversized; for example, although the Scale Labels are identified as Arial 6pt text, they are relatively large compared to the graph Body. This makes it easier to illustrate the alignment of the Scale’s elements with each other, and with the Body’s elements. Once the relationships have been rationalized and an API for Bullet Graph creation is developed it will be easy to configure the various dimensions, colors, and other properties of the graph to provide enough flexibility to render high quality presentations in different contexts.

As shown here, the graph’s Body and Scale are abutted, joining seamlessly at their common edges.

The individual Scale marks are laid out evenly, spanning the full length of the Body, with projections on the baseline and terminus of the body to accommodate the multiple requirements for: 1) aligning the midlines of the Ticks and Labels; 2) aligning the leftmost Scale element’s Tick with the Body’s baseline; and 3) aligning the rightmost Scale element’s Tick with the Body’s terminus. These are show below.

Each point on the Scale is identified by a Tick mark and a text Label. The Tick is used to precisely denote the point on the graph corresponding to the Scale point’s value. As the Tick has a definite width (it’s really a rectangle), it’s essential to be specific in determining how to align it with the Graph Body in order to accurately and precisely denote the correct value. Although seemingly simple, there are subtleties involved, as shown in the examples below.

The leftmost Scale point’s Tick mark is left-aligned with the baseline of the Graph Body. This is different from the other Scale Tick marks, but is a visual convention that works well. As always, the Label is center-aligned with the Tick; this will almost in all cases cause the Label’s bounding box to extend to the left of the baseline of the Body. Handling text has particular considerations—look for a future article on handling the various text elements found in Bullet Graphs.

The Scale’s midpoints’ Tick marks are right-aligned with the corresponding value, scaled to match the length of the Graph Body. The importance of this alignment is revealed when the Tick’s value corresponds to the value of one of the Qualitative Bars, in which case they are right-aligned on the value. The basic principle here is that the leading edge of the element corresponds to the value being visually coded.
The Label is center-aligned to the Tick.

The rightmost Scale point’s Tick mark is right-aligned with the point’s value, scaled to the Graph Body. This is the same convention as for the midpoints.
The Label is center-aligned to the Tick; this will cause the label to extend to the right of the Graph Body, in almost all cases.

Bullet graph design: Body Geometry

Examining the geometry—the dimensions of and relationships between—the various elements of the body and quantitative scale.

See Bullet graph design: nomenclature for the nomenclature used in describing the Graph Body, Text Label, and Quantitative Scale.

This is a copy of the first Bullet Graph Stephen Few presents in the Bullet Graph specification, without the Text Label.

This study is an exercise in determining the geometry, dimensions, and alignment of the various elements of the Graph in order to assist the creation of a detailed design specification for other bullet graphs that conform to this example and can be created programmatically.

For the purposes of this article – describing the geometry and relative alignments of the graph’s components the Scale’s elements have been rendered somewhat oversized.

This diagram has exploded the different bars of the graph to reveal their layering. (Well, actually, it slipped the bars down, but (exploded” is a much more dynamic term.)

The top-down ordering shown matters in that each bar hides everything beneath it in the final rendering, making it much easier to build the final image.

The * indicates that there may be more than one middle bar, i.e. when there are more than three Qualitative Ranges.

In this diagram the Comparative Measure is placed on top of the Performance Measure; the specification isn’t clear on this and as long as they are both are colored 100% black and are have these dimensions and positions it seems not to matter. (while this may not matter in normal circumstances it may become significant in some edge cases. Look for further studies on this and related topics)

As illustrated in this diagram the baseline dimensions of the  graph have been normalized to 200 units wide and 12 units high. (Inkscape assumes a unit of pixels if none is specified, and this works well for our purposes.)

The dimensions of 200×12 provide a good approximation of the dimensions of the Canonical Bullet Graph, and have the advantage  of providing easy-to-work-with integer values for most of our  calculations employed in programmatically constructing bullet graphs. The 200 units width is easy to scale for both absolute and percentage scales, and the 12 units height makes it easy to center the Comparative and Performance measures along the horizontal axis for a variety of the possible values that their heights may end up being (12 is easily divided into 1/6s, 1/4s, 1/3s, 1/2).

It’s assumed that the bottom Qualitative Range Bar will span the full 200 units width, and that the other graph elements will be scaled  proportionally to it.

The Performance Measure bar is defined to be one-third of the width of the graph baseline value for the bar group, or 4 units. When rendered on top of the bar group this results in the Performance Measure occupying the center third of the bar group’s height, which provides for  good visual discrimination between the elements.

The Performance Measure is left-aligned with the graph bar group and its width is proportional to its fraction of the maximum scale value of the graph, normalized to the 200 units of the width of the graph bar group.

The Comparative Measure measure is defined to be a rectangle 2 units wide and 10 units high.

When rendered horizontally aligned atop the graph’s Qualitative Range  bars there is a 1 unit gap on either side of the Comparative Measure, aiding the viewer’s visual location of its position. When rendered atop the Performance Measure the Comparative Measure extends 3/4 of the  way across the visual gap between their outer edges of the PM and the edge of the bar group.

The CM’s y coordinate is calculated to achieve its horizontal alignment with the graph bar group and the Comparative Measure.

The CM’s x coordinate is calculated to be proportionate to its fraction of  the maximun scale value of the graph, normalized to the 200 units of the  width of the graph bar group, minus the 2 units of the CM’s width. This ensures that the leading edge of the CM is exactly geometrically aligned with its value.

Bullet graph design: nomenclature.

Describing the elements of bullet graphs is the first step towards being able to discuss and design them.

This diagram, copied from Steven Few’s Bullet Graph Design Specification shows the analytical elements of a standard bullet graph:

• the data – the performance measure, comparative measure, and the qualitative ranges;
• the quantitative scale provides the analytical framework for the data;
• the text label identifies the business context for the data.

This diagram segments the bullet graph into its structural parts.

• The graph body is the graph’s core containing the data.
• The quantitative scale provides the numerical framing for the body’s data.
• The text label identifies the business context.

This diagram segments the graph into its geometric and textual elements.
The geometric elements have fixed dimensions, orientations, and alignments, and are therefore easily constructed and positioned in the 2D graphical space.
The text elements are different in that their dimensions will vary depending upon their contents. Most notably, the characters, and font style and size will directly affect the 2D graphical space required to present the text. Different rendering systems will further affect the text display dimensions.

Considering the bullet graph with separate and distinct geometric and text elements simplifies the process of constructing graphs from real data.
Creating the geometric elements is straightforward, as their dimensions and coordinates are invariant across rendering systems.
Creating the text elements contents is similarly straightforward. Determining their dimensions and coordinates (D&Cs) is difficult due to the differences to rendering text by individual SVG user agents. This makes calculating the text elements’ D&Cs effectively a best-guess approach. In practice, this may be “good enough”, but mechanisms must be provided for specifying the actual D&Cs producing the optimal results for a given user agent—this will be covered in future posts.

We’re in the psychology business, not the technology business.

As BI professionals our goal must be to make and keep our clients happy.

It seems like such a simple thing, but all too often our client’s happiness gets short-shrifted in the press of getting the “real” work done. This is particularly true in Big BI environments where the bulk and complexity of the enterprise-scale BI technology and tools overwhelms the available amount of time, energy, effort, and resources. There’s so much to do just to get the machinery in place and working that the whole point of the work—delivering high quality information to business decision makers—becomes pushed to the side. And once the focus shifts it’s very difficult, usually traumatic, to get it back on the proper target.

How, then, do we keep our clients happy?

Simple: we deliver business value early and often.
This requires that we learn their needs, and what will satisfy them.

We start off by learning the first thing our client wants to know—the information that, when available, lets them understand something meaningful about the state of their business—and we provide it.
We then learn the next thing, and provide that.
And we make sure that our clients’ needs for high quality information continue to be the driving force behind everything we do. The corollary to this is the guiding principle for our work:

Do those things that deliver information to those who need it. And do only those things—if we cannot see the direct path between what we’re doing and the delivery of high quality information to those who need it we must stop what we’re doing and do something else for which the path is clear. There’s always more than enough straight-path stuff to do.

Some skeptics will say that this is too simple, that it ignores the “real work” conducting the deep and broad analysis, of contemplating and conducting the enterprise-spanning data and information rationalization, of designing the comprehensive data architecture, of designing and implementing the data marts and warehouses and ETL processes, policies, procedures, and programs. All the technical stuff that’s absolutely necessary to get the client the totality of the enterprise information, because, after all, that’s what they really need.

Isn’t it?

Well… no.

The client always needs the next report, the next analytical framework, the next executive monitor, the next delivery of information. Providing the next thing, and then the next, and continuing on this path ensures that the client’s needs continue to be met. Which has a multitude of benefits, all of which contribute to the client’s happiness with their results, and with us.

What about all the “real work”. Doesn’t it matter?

Of course the “real work” matters. But only insofar as it supports delivering high quality information to the client. All the machinery, all the analysis, design, and construction only matters, only has value, it contributes to meeting the client’s need for information.

As BI professionals it is our responsibility to deal with the machinery. To do the analysis, design, and implementation of everything that lies beneath the surface (or under the covers if you prefer that metaphor). We get paid to handle that stuff. If we cannot keep the “real stuff” appropriately out of sight it adversely impacts the client. This isn’t to say that the workings can be wrought shabbily. On the contrary, all the technical parts need to be the best they can possibly be so that when they are examined, as they always will be, they will be able to withstand the most critical scrutiny.

It turns out to be true that continuing to identify and satisfy the client’s needs is also the best way to learn everything that’s required to design and implement the correct machinery. The contributions to our learning, the feedback we get from the client as we satisfy their needs, is absolutely critical in helping us steer the best course towards the best design and implementation of the large-scale elements of the comprehensive business intelligence solution.

A Note on the History of BI

Way back in the old days business intelligence meant data processing and reporting.

The devices for publishing business data were line printers and character-based terminals, usually of the IBM 3270 family.

Reports were pretty straightforward affairs: appropriately collected, filtered, sorted, and aggregated data was presented in tabular format, with no or very little formatting.

This worked well for addressing a very large variety of business information needs (and remains an excellent solution for these needs today, albeit with vast improvements in formatting).

Analytics were restricted to varying the elements of the reporting process. Record selection, varying the contents of a report by including or excluding records based on data filtering, was the most common, permitting the same “report” to be generated with different data populations. This made is fairly straightforward to compare data over time or across meaningful business dimensions e.g. divisions, regions, product lines, etc.

Changing the structural characteristics of a report – reordering columns or changing sorting or aggregation, makes it very difficult to compare like-to-like. Providing mechanisms for changing the structure of reports has been possible for as long as reporting tools have existed, but for a long time the practice of structurally altering reports was not widespread.

The advent of non-mainframe computing environments introduced all sorts of new reporting capabilities.

In particular, graphics-capable computing led to the advent of basic business graphics. Bar and line graphs permitted the visual presentation of data in ways that permitted the observation and interpretation of quantitative values of and relationships between similar data sets.

Over time the ability to produce a wide variety of graphical forms, with increasingly varied visual attributes, grew. And grew, and grew, and grew.

Pretty soon we were awash in data graphing in all its glory. And gory misapplication of visual effects.

For although there is a long history of study and practice in the visual presentation of quantitative data the practice of presenting data has languished in a world much like the early days of the World Wide Web when everyone who could sling together some HTML took advantage of all the visual features and created truly hideous visual monsters. Well, at least a fair number of them did.

Over the years there have been some excellent works published that provide good, solid, practical advice on the presentation of data in a business environment. Edward Tufte’s works are the bedrock upon which most of the modern best principles and practices rest. Stephen Few’s books are marvelous in their sheer practicality in providing good solid examples of how, and just as importantly how not, to present data.

Where once we were restricted to single-report production and publication we are now faced with an embarrassment of riches. We can dynamically construct reports of dizzying sophistication and subtlety with interactive capabilities that let us scour the full range and depth of the organization’s data. We can build dashboards that faithfully mimic the cockpit of a Formula 1 racecar, and all too often do (more on this in future installments).

We can create executive summary monitors that elegantly, completely, concisely, and cogently present the full range of relevant data necessary for a business decision maker to understand the full spectrum of the state of his business. Some would call these dashboards, but that word has been usurped and polluted by the marketeers, the Formula 1 cockpit jockeys, and has lost all of its dignity.

In this age of Big BI we are faced with an entrenched paradigm of monolithic vendor-driven enterprise-scale highly complex all-inclusive technology platforms that are thought to be (because they’re promoted to be) the One True Way for implementing Business Intelligence in the modern organization.

These behemoths are explicitly designed to consume and digest all of an enterprise’s critical business data into Data Marts and Warehouses and provide the full suite of analytical and publication facilities that satisfy each and every one of the needs of anyone who needs to understand the organization’s data.

The sad reality is that from the only perspective that really matters – delivering high quality actionable business intelligence (information) to business decision makers – the large majority of Big BI initiatives fail miserably.

This blog is my address to this state of BI, and explorations in how to do it better.

We, as Business Intelligence professionals, can do better.
We must do better.
We can do better.
We shall do better.

Chris Gerrard

Better BI Manifesto

Business Intelligence is many things, but ultimately is the delivery of timely, high quality business information to business decision makers.

Better BI is an approach to business intelligence that recognizes the primacy of the delivery of information, and that other activities and technologies are valuable in proportion to their support of the primary goal.

Better BI in practice recognizes the importance of adopting a model of early and continuous delivery of information.

Better BI advocates the value of the following:

• Constant interaction with business decision makers in order to satisfy their information needs.
• Ruthlessly keeping a focus on information delivery, immediately and continually.
• Intimate analytics as the mechanism for reducing the distance between business decision makers and insights into their data.
• High quality analytic information design as a critical element in communicating the stories the data has to tell.
• High quality analytics developed in close collaboration with business decision makers, via intimate analytics, serve as the information designs for enterprise BI systems.

Better BI extends the traditional data warehouse-based business intelligence paradigm. The traditional model tends to shift the perspective of the BI initiative away from delivering information towards developing the highly complex technology infrastructure that will ultimately (hopefully) deliver valuable information.

Introduction

Business Intelligence as an activity has the goal of delivering information—intelligence—to business decision makers.

This blog is devoted to exploring the practice of BI, and ways in which it can be improved by delivering higher quality information faster, at lower cost, and more responsive to a constantly changing business environment.

Beware BDWUF – Big Data Warehouse Up Front

Data warehouses are good, useful, and tremendously valuable in relationship to their contribution to providing the data-based information essential to making timely, high quality business decisions. Properly designed and implemented, fronted with useful and meaningful reports, user-operated analytical frameworks, dashboards, scorecards, and the like, data warehouses effectively fulfill their fundamental purpose.

There are, however, far too many examples of data warehouses that have consumed large, even enormous, amounts of time, energy, effort, money, executive attention, and other resources, without delivering a reasonable return on these investments. Why has this come to be?

One recurring theme is the phenomena of the BDWUF – Big Data Warehouse Up Front.

BDWUF (pronounced bee-dee-woof) refers to the practice of investing tremendous amounts of effort into deep analysis of the business along with designing and implementing a comprehensive enterprise-wide data warehouse that completely addresses the wide variety of considerations and constraints involved in delivering the “one version of the truth” to business decision makers.

The emphasis on creating the whole enterprise-wide data warehouse-based environment and systems has the overall effect of shifting the emphasis away from delivering high quality, timely, effective information to the activites required to design and construct the technological artifacts. There is a very real danger, and high liklihood, that building the technology, and maintaining the technology-constructing bureaucracy, becomes the whole point. And that the outputs finally delivered to the business decision makers will be of relatively little real value.

If not BDWUF, then what?

Assuming that BDWUF is a less-than-optimal approach to delivering business intelligence to business decision makers, is there an effective alternative?

The answer is yes. Better BI is an approach to business intelligence that stresses the importance of delivering timely, high quality business information to business decision makers. Better BI is a superset of data warehouse-based business intelligence that recognizes the importance of working intimately with business stakeholders throughout the entire process of developing and delivering the information they require.